アプリの組合せで専門家でなくてもAI技術を利活用できる

プロジェクトオーガナイザの吉田聖書よしだみふみです。

今回は、岡山大学が10月18日に出した「個人で手軽に AI(人工知能)による画像自動分類が可能に」というプレスリリースを取り上げます。

岡山大学のプレスリリースはこちら。
個人で手軽に AI(人工知能)による画像自動分類が可能に!~様々な分野の研究の省力化に貢献~

Read the rest of this entry »

日本語の文章を要約するAI「ELYZA DIGEST」

プロジェクトオーガナイザの吉田聖書よしだみふみです。

8月26日に、東大の松尾研究室から誕生したスタートアップ企業ELYZAが、日本語の文章を要約するAIを開発して、デモサイトを公開したというニュースを取り上げます。

プレスリリースはこちら
https://prtimes.jp/main/html/rd/p/000000011.000047565.html

Read the rest of this entry »

北國銀行が日本で初めて勘定系システムをクラウド化

プロジェクトオーガナイザの吉田聖書よしだみふみです。

今回は、石川県の金沢市に本店を置く北國銀行が、今月からクラウド環境での勘定系システムを稼働させたというニュースを取り上げます。

Read the rest of this entry »

スーパーコンピュータ「富岳」使ってみる?

プロジェクトオーガナイザの吉田聖書よしだみふみです。

去る3月9日に、
スーパーコンピュータ「富岳」が完成した
というニュースがありました。
ご存じの方もいらっしゃるかと思いますが、
私はこれを聞いて違和感を覚えました。

Read the rest of this entry »

パソコンをリサイクルに出してみた

プロジェクトオーガナイザの吉田聖書よしだみふみです。

今週はシルバーウィークということで
軽めの話題をお送りします。

職場ではなく、ご家庭でのパソコンの
リサイクルはどうしていますか。

今回初めてリサイクルに出したので
その様子をレポートします。

Read the rest of this entry »

新型コロナの検査結果にも応用できるベイズ理論

プロジェクトオーガナイザの吉田聖書よしだみふみです。

近年のAIブームによって、
特に機械学習の分野において
ベイズ統計学(ベイズ理論)が注目されています。

数学は苦手という方でも
「条件付確率」といえば
何となく覚えているという人もいるのでは。

それが、

新型コロナの検査で「陽性」と診断された時に
本当に感染している確率は?

という問に答えるものであるということです。

Read the rest of this entry »

ハードディスク(HDD)の準備と後始末

プロジェクトオーガナイザの吉田聖書よしだみふみです。

神奈川県が破棄したはずのハードディスク(HDD)が
転売されて重要データが流出した
というニュースにはショックを覚えました。

ある会社で複数のWebサービスを運営しており、
10年くらい前、私が業務委託で
リース切れに伴う物理サーバの更改を
支援した時のことを思い出しました。

Read the rest of this entry »

Last name と first name

ITコーディネータの吉田聖書よしだみふみです。

自分の氏名を書く時、
姓と名をどの順番で書いていますか。
あるいは名乗る時はどうでしょう。

きっと読者の多くの方が
姓→名の順番だと答えるでしょう。
では、海外へ行ったり、
ローマ字で書く場合はどうでしょうか。

Read the rest of this entry »

ドイツのトイレットペーパーは何枚重ね?他、小数点と単位とお金のこと

ITコーディネータの吉田聖書よしだみふみです。

前回に引き続きドイツでの話です。

日本でも、初めて行くタイプのお店では
どうやって買い物をし、どうやって支払えばよいのか
分からなくて戸惑うことがあると思います。

その地域なりの習慣や流儀があったり、
それで分からずもたもたしていると後ろで待っている人に迷惑かもしれない
などと思うと余計に焦ってしまいますよね。

今回はそんな、細かいけどちょっと戸惑った、
数字とお金について気づいたことを書きたいと思います。

Read the rest of this entry »

データベースの索引がイケてない話

以前、とある業務システムで検索スピードが要件を満たさずにリリースが延期されたという話を耳にしたことがあります。それを聞いた時、かつて少し関わっていた現場で、検索するとCPU負荷が100%に張り付くシステムや、ちゃんと動いていたのにある日を境に検索がタイムアウトするようになったシステムの存在を思い出しました。

この手の話はデータベースの索引が適切でないことに原因があることが多いのですが、データベース設計の教科書でも索引は基本的な単元であるにもかかわらずわりと良く聞く話でもあったりします。プログラムはゴリゴリ書けるけど、DB設計をきちんと学んだことが無い人が作っているという可能性もあるのですが、もしかしたらある程度きちんと機能する索引を付けるにはそれなりに経験を積んでセンスを磨く必要があるということなのかもしれません。

索引は検索キーやソートキーに付与するというのが基本ですが、複数カラムを指定して検索する場合にその索引が使われなければ、別途使われるような索引を付与するといったことをします。ただ、あまり索引を付け過ぎると更新処理のパフォーマンスが落ちるので、検索スピードが欲しい場合はマスタとは別に検索用のテーブルを用意することもよくあります。最初は普通に結合して選択していたものが、段々パフォーマンスが落ちてきたために途中で検索用テーブルを追加するといったことは別におかしいことではありません。

適切な索引が無ければどんなにSQLを効率的に記述してもパフォーマンスは出ませんし、また、基本的な索引は理論だけで行けるとしても、RDBMSの実行計画は実際にテーブルに格納されているデータの件数だけでなく内容によっても変わってきます。なので、もし絶対に止めてはいけないようなシステムの場合は、テストの段階で本番さながらのテストデータを使って本番さながらの件数を格納した上で動作を確認しチューニングする必要があります。

チューニングの作業は私は結構楽しいと思っていますけれど(例えばチューニングして検索スピードが10分の1になったら楽しくないですか?)、面倒くさいと感じる人はなるべくやらずに済ませたいと思ってしまうのでしょうか。