ある日の飲食店で
先日、友人と二人で飲食店に行きました。最近よくあるタッチパネル注文のお店です。
私たちは各々、食べたいものをタッチパネルで注文しました。私はAのご飯、Bのおかず、Cのサイドメニュー。友人はDのご飯、Eのおかず、同じくCのサイドメニュー。
しばらくして、料理が運ばれてきました。しかし、膳に入れられた料理がてんでバラバラだったのです。
私のところにはAとBだけ。友人のところにはD、E、そしてCが二つ。私のCはどこに行ったのか。友人の膳にまとめられていました。
なぜこうなったか
注文した時点では、私と友人は別々のコンテキストで操作しています。「私はA+B+C」「友人はD+E+C」という明確な対応関係がある。
しかし、この注文がキッチンに届いた時点でコンテキストが消失しています。キッチンが受け取るのは「テーブルXからA、B、C、C、D、Eの注文」という情報だけ。誰が何を頼んだかは伝わらない。
配膳する店員は、料理と人のマッピングを推測するしかありません。Cが二つあるなら、まとめて片方に置く方が合理的に見える。でもそれは間違いです。
昔はこの問題は起きなかった
コロナ禍以前、人が注文を聞いていた時代を思い出してください。
「こちらのお客様がA定食、そちらのお客様がB定食」。店員は注文を聞く時点で、誰がどれを頼んだかを暗黙的に把握していました。キッチンに伝える時も「Aは手前のお客様、Bは奥のお客様」と伝えられた。
A定食・B定食のようなシンプルな注文なら、タッチパネルでもミスは起きません。品数が少なければ、配膳時に推測しても正解率は高い。
しかし、メニューの多様化が進み、注文の組み合わせが複雑になりました。サイドメニューを追加したり、単品を組み合わせたり。そうなると、配膳する側の確認作業が追いつかなくなり、結果的にサービスの質が落ちてしまう。
入口の最適化が出口を壊す
タッチパネルは注文を受ける側のコストを劇的に下げました。人件費の削減、注文ミスの防止、人との接触を減らすコロナ対策。入口としては大成功です。
しかし配膳する側の判断コストは考慮されていなかった。むしろ、人が注文を聞いていた時代には自然に保持されていたコンテキスト（誰がどれを頼んだか）が、タッチパネルによって失われてしまった。
入口を最適化した結果、出口のプロセスが破綻する。 部分最適が全体のサービス品質を下げてしまう構造です。
これ、AI駆動開発でも起きていませんか
ここからは私の本業の話です。ソフトウェア開発の現場で、同じ構造の問題を目にします。
AIコーディングツールの導入によって、コードを書く速度は劇的に上がりました。これはタッチパネルで注文が簡単になったのと同じです。入口の最適化です。
しかし、書かれたコードをレビューし、承認し、統合するプロセスはどうでしょうか。
- AIが高速にコードを生成する → レビューする人間の負荷が増える
- シンプルなタスクなら問題ない → 複雑なタスクで破綻する
- 誰がどの意図で変更したかのコンテキストが薄くなる → マージ時に推測が必要になる
構造を並べてみると、対応関係が見えてきます。
タッチパネルの配膳ミスと同じです。入口（コード生成）を最適化しても、出口（レビュー・承認・統合）のプロセスが従来のままなら、全体のスループットは上がらない。 むしろ、品質が下がるリスクすらある。
解決の方向性
飲食店の話に戻ると、解決策はいくつか考えられます。
- 注文時に「誰が何を頼んだか」をシステムに記録する（座席ごとの注文管理）
- 配膳時にコンテキストを復元できる仕組みを作る（伝票に座席番号を紐づける）
- そもそも配膳ミスが起きにくいメニュー設計にする（セット化）
AI駆動開発でも同じです。
- コードに意図を残す: README、設計書、コミットメッセージに「なぜこう書いたか」を明記する。AIが生成したコードでも、人間が意図を補足する
- レビュープロセスを再設計する: AIの生成速度に合わせて、レビューの粒度や承認フローを見直す。全てを人間がフルレビューする前提を変える
- そもそもの複雑さを減らす: タスクをシンプルに分割し、コンテキストが消失しても影響が小さい構造にする
入口を最適化するなら、出口も一緒に再設計する。当たり前のことですが、便利なツールを導入する興奮の中で、忘れがちなことでもあります。
おわりに
飲食店のタッチパネルも、AI駆動開発も、「便利になった」のは間違いありません。ただ、便利になった部分だけを見て、全体のプロセスを見直さないと、思わぬところでサービスの質が落ちる。
入口の最適化は出口の最適化とセットで初めて意味がある。次にタッチパネルで注文するとき、ちょっとだけこの話を思い出してもらえたら嬉しいです。