本文へスキップ
AZASLAB
← Journal
7 min read AI協働開発健康

連載「carb-icr 開発日誌」· 第5編/全14編

どこから出てくるか、を先に調べる

自動化の8割は、データの出口調べでした(開発日誌 5)

何を自動化するかが決まっても、すぐにAIには飛びつきませんでした。先にやったのは、欲しいデータがどこから、どんな形で、いつ出てくるかを1つずつ確かめること。その地味な出口調べが設計の大半だった話を、一緒に。

安宅春樹 (Ataka Haruki)

— AZASLAB代表 ・ AIエージェント開発ディレクター

— Shimizu Fumio Architects Co., Ltd. 取締役

「どう作るか」の前に、つまずく場所

何かを自動化しようと決めると、頭はすぐに「どの技術で作ろう」へ向かいがちです。けれど、技術を選ぶより前に、たいてい別の場所でつまずきます。今日はその、見落とされやすい手前の工程を一緒に見ていきます。

前回は、道具の名前で聞くのをやめて、課題の名前に問いを立て直したところまででした。立て直した課題は、毎食の手入力をなくしたい、です。さあ作ろう、という段になって、私はすぐにはAIに飛びつきませんでした。先にやったのは、もっと地味な作業です。欲しいデータが、どこから、どんな形で、いつ出てくるのか。その出口を、1つずつ確かめていくことでした。今日は、その出口調べの話をします。結論から言うと、設計の8割は、ここで決まりました。

立派な技術も、出口がなければ繋がらない

自動化というと、つい中身の高度な技術に目が向きます。賢いAI、うまい処理。けれど実際に手を動かすと、もっと手前でつまずきます。そもそも、必要なデータを手に入れられるのか。手に入るとして、それは使える形か。使える形だとして、必要なときに間に合うのか。この3つが通らないと、どんなに中身が立派でも、何も繋がりません。中身の良し悪しは、データが入ってきて初めて問える問題で、入口が塞がっていれば、議論する土俵にすら乗らないのです。

私が自動化したかったのは、食事の糖質でした。ふだんは、ある記録アプリで糖質を調べています。なら、そのアプリからデータを引っぱってくればいい。最初はそう考えました。引っぱれる、という見込みが正しいかどうかは、出口を実際に叩いてみないと分かりません。そこで、調べ始めます。

出口を、1つずつ叩いていく

まず、いつも使っている記録アプリの出口を確かめました。データを書き出す機能はあります。ただ、その形が問題でした。書き出しは、まとめてファイルで送られてくる方式で、最大でも数か月分をいっぺんに、というバッチ処理です。これは、過去をふりかえる用途には向くけれど、私の用事には合いませんでした。カーボカウントで必要なのは、食事の前に、いまこの食事の糖質です。あとからまとめて出てくるデータでは、その瞬間に間に合わない。出口はあったけれど、出てくるタイミングが、用事と噛み合っていませんでした。

ここで1つ、原則を持ち帰れます。データがあることと、使えることは別だ、という当たり前です。書き出しの機能がある、と聞くと、つい「ならデータは取れる」と早合点します。でも、取れる形が違ったり、取れるタイミングがずれていたりすると、あるのに使えない。出口の有無だけでなく、形とタイミングまで確かめて、はじめて使えるかどうかが分かる。どこから、どんな形で、いつ。この3つを別々の問いとして立てる必要があったのは、このためでした。1つにまとめて「取れるか」とだけ問うと、形やタイミングのズレが問いの網からこぼれ落ちます。

次に、スマホの健康情報のハブ経由で受け取れないか、を調べました。各アプリのデータを1か所に集める、いわば合流地点のような仕組みです。ここに食事のデータが流れてくれば、そこから受け取れる。調べると、その記録アプリは、ちゃんとこのハブに対応していました。ところが、流している中身を確かめると、血糖や体重や歩数は来るのに、肝心の食事、つまり栄養素は対象外でした。合流地点まで道は通っているのに、運んでほしい荷物だけ載っていない。対応している、という事実と、ほしい中身が流れている、という事実は、別物だったわけです。糖質を自動で受け取る道は、ここでも塞がっていました。

3つ目に、インスリンの量はどうか、も確かめました。これは、ポンプという医療機器が握っていて、その記録を外へ取り出す公式の道は、私の環境では見当たりませんでした。出口としては、いちばん固く閉じている。ただ、ここで見方を1つ加えられます。インスリンの量は、打つ瞬間に自分で決めて、自分がいちばんよく知っている、1桁か2桁の数字です。3つの入力のうち、これだけは手で打っても、たいした手間ではない。自動化の値打ちは、手入力の重さで測れます。重い作業を自動化すれば見返りは大きく、もともと軽い作業を自動化しても見返りは小さい。だから無理に自動化を追わず、ここは手入力のままでいい、と早々に割り切れました。出口の開き具合と、自動化する価値は、データごとに違う。固く閉じた道を、力ずくでこじ開ける必要はありませんでした。

調べるほど、惜しいところで道が途切れていきます。それでも、この地道な確認には、ちゃんと意味がありました。

塞がった道からも、収穫はある

出口を叩いて回って分かったのは、糖質の自動取得が、思ったより難しいという事実でした。これは行き詰まりではなく、収穫です。塞がっている道がはっきりしたぶん、残る道に集中できる。もし出口を確かめずに「きっとどこかから取れるだろう」と作り始めていたら、途中で行き止まりにぶつかって、作ったものごと無駄にしていたはずです。先に塞がりを知る価値は、作り直しを未然に防げるところにあります。

そして、調べる過程には副産物もありました。食事は流れてこなかった合流地点に、血糖の値は流れてきていたのです。糖質の出口を探していたはずが、血糖という別のデータの出口が見えてきた。このときはまだ気に留めませんでしたが、この副産物が、のちに話の流れを大きく変えることになります。1つの出口を丁寧に覗くと、目当ての荷物が無くても、隣に何が積んであるかまで見える。出口調べは、探していた答えだけでなく、探していなかった答えも運んできます。

「どこから」を確かめると、選択肢が並ぶ

出口を一通り叩いたことで、ようやく現実的な選択肢が、机の上に並びました。写真から糖質を推定して、調べる手間ごと自分の側で完結させる道。事後のふりかえりは、まとめて出てくる書き出しでまかなう道。血糖のように、合流地点から受け取れるものは受け取る道。どれも、出口の形を確かめたからこそ、それぞれの向き不向きが見えた選択肢です。

逆に言えば、出口を調べる前に技術から決めていたら、この並びは作れませんでした。「この技術で何ができるか」ではなく、「このデータはどこから、どんな形で出てくるか」。問いの向きが、前回と同じく、ここでも効きました。前回は道具から課題へ向きを変える話でしたが、今回はその課題を、データの出口という現実の地形に下ろす作業です。自動化の設計は、賢い中身を考える前に、まず周りの配管を確かめる作業から始まります。

あなたが何かを自動化したくなったら

もしあなたが、何かの作業を自動化したいと思ったら、どの技術を使うかを考える前に、紙に一本の線を引いてみてください。欲しいデータは、どこから出てくるのか。それは、いつ、どんな形で出てくるのか。その出口が、自分の用事のタイミングと噛み合っているのか。

派手ではありません。でも、ここを1つずつ確かめておくと、あとで行き止まりにぶつかって作り直す、という回り道を避けられます。確かめる順番にも、ちょっとした効用があります。先に出口を見ておけば、使えない道に時間を注ぐ前に、それを使えないと判断できる。出口の調査は、設計の準備運動ではなく、設計そのものでした。中身の高度さより先に、データの出口。地味な確認の積み重ねが、いちばん効きました。

そして、出口は1つではありません。糖質、血糖、インスリン。同じ食事の記録でも、データごとに出口の形も、開き具合も、自動化する値打ちも違っていました。一本ずつ叩いて、開いている道は使い、固い道は手で補い、噛み合わない道は見送る。この仕分けができたこと自体が、出口調べの収穫でした。仕分けの基準は、欲しいかどうかだけでなく、出口の形と、自動化の値打ちの掛け合わせで決まる。そう考えると、塞がった道を見送る判断も、迷いなく下せます。

次回は、この出口調べの途中で見つけた血糖という副産物が、話の中心をまるごと入れ替えてしまった話を。思っていた難所は、別の場所にありました。


これは、自分の治療のために作っている自作自用版での話です。広く公開しているのは記録と集計に絞った carb-icr(無料・通信なし・ブラウザで動くPWA)。プロジェクトの概要は carb-icr のプロジェクトページ に。

本アプリは記録と集計の補助で、表示される値はすべて参考です。診断・治療、インスリン投与量の計算、治療パラメータの決定は行いません。投与量・治療方針は必ず主治医の指示に従ってください。