先日、AIエージェントとの対話で小さな競合事故の話をしていて (相槌が誤って承認扱いされた件です)、「私からAIへ送る入力に送信時刻のメタデータが付いていれば検出できるのに」という話になりました。私は反射的に「でも通常時は出力がtimestampだらけになって煩瑣では」と返した。返ってきた答えで、少し目が覚めました — 人間の画面には出さず、AIに渡すpayloadにだけ載せればいい。
言われてみればそれだけのことです。でも私は、UIというものを無意識に「人間が見るもの」とだけ考えていました。操作者がAIになった世界では、AI向けの接面は、人間向けの画面とは別に、独立に設計できる — この当たり前に、気づいていなかった。
実は、ずっとやっていた
気づいてから振り返ると、私はこの半年、無意識にそれをやっていました。
- 読者がAIである手順書。人間向けなら図と画面キャプチャで書くところを、AIに教える手順は、一意な様式・grepしやすい構造・そのまま実行できるコマンド断片で書いてきました。人間なら多少曖昧でも読めてしまいますが、AIの読み取りの精度は、書式が揃っているかどうかで大きく変わります
- 実行できるメモ。私はもう、自分用のメモを全く取りません。聞いた端からAIに説明して、記憶してもらい、後で教えてもらう。あわよくば代わりにやってもらう。人間のメモは受動的な保管で、思い出す仕事も実行に変換する仕事も自分に残りますが、AIに預けたメモは保管場所がそのまま実行者です。記録と委任が、同じ一つの動作に融合している
- AIが記帳する台帳。作業中に見つけた技術的負債を「日付・作業・負債の性質・発生したコスト・規模」の決まった行形式で台帳に追記させる運用を回しています。行形式にしてあるのは、後で読むのも集計するのもAIだからです (この様式自体もAIの発案で、私は承認しただけです)
世間でも同じことが起きている
この発想は私の発明ではなくて、業界のあちこちで同時多発しています。Webサイトが人間向けのHTMLと別にAI向けの入口を置くllms.txt。ツールの応答を「AIが読む前提」で構造化するMCP。どれも同じ一つの認識に基づいています — AIは一級のユーザーである。そして人間とは別の接面を要求する。
「機械向けの接面なら、REST APIやRPCとして大昔からあるじゃないか」と思われるかもしれません。私も書きながらそう思いました。違いは、消費者が散文を読める機械になったことです。APIの契約は、開発時に人間がドキュメントを読んでクライアントコードに翻訳することで結ばれてきました — 機械同士の接面に見えて、結節点には必ず人間の開発者がいた。AI向けの接面は、実行時にAIが読んでそのまま結ばれます。ドキュメントがそのままクライアント実装になる。だから要るのは、OpenAPIのような形式的完全性ではなく、意図や注意 (「このフィールドは歴史的経緯で時々嘘をつく」「この操作は本番に届くから止まれ」) まで運べる、規律ある散文 — APIスキーマと人間向け文書の中間の様式です。llms.txtもMCPも、よく見るとその中間層に立っています。
設計原則として言えそうなこと
まだ半年の実感ですが:
- 人間向けの表示とAI向けのメタデータは、別チャネルでよい。 冒頭のtimestampの話です。人間のUXを汚さずに、AIの判断材料だけを増やせる。両者を1つの画面に同居させようとするから煩瑣になる
- 読み手がAIのドキュメントは、味わいより一意性。 同じことは毎回同じ書式で書く。手順は散文でなく実行可能な形で置く。「行間を読ませる」文章は、人間には親切でもAIには罠になります
- 記録は実行者の近くに置く。 知識を人間のメモに置けば、実行のたびに人間が翻訳することになる。実行者がAIなら、AIが読める場所に、AIが読める形で置く — メモと委任の融合は、この原則の帰結です
逆向きの含意もあります。操作の主体がAIに移っていく仕事では、人間が手で操作する前提のUIは、静かに宛先を失っていきます。丁寧に作られた画面が、悪いわけでもないのに使われなくなる。道具の良し悪しではなく、宛先の変化です。
インターフェースの歴史は、ユーザーの範囲が広がる歴史でした。専門家だけのものだったコンピュータがGUIで万人のものになったように、いま「ユーザー」にAIが加わったところです。だとすれば、AI向けの接面設計は、これから数年の設計論のかなり大きな部分を占めることになると思います。
(この連作は、AIエージェントを業務のレガシーシステム保守で半年ほど運用して溜まった実践則を、1本1則で書いていくものです。下書きは当のAIが書き、文責は私にあります)