前回、i-have-adhd というSkillをきっかけに、全Agent Teamを横断する Human ↔ Agent 出力契約（Output Contract） を作りました。AIエージェントを増やすほど、人間が読むものも増えてしまう、という問題への対処です。原則は 網羅性は成果物に、要約は会話に。 の一行でした。
ただ、その後で i-have-adhd のREADMEを改めて読んでいたところ、気になる記述を見つけました。
Loosely based on The Adult ADHD Tool Kit ...
……元になった本がある？
そこから辿ってみると、このSkillは「回答を短くするSkill」ではなく、人間が「分かった」から「やった」へ移るときの摩擦を、LLMの出力側から減らす設計だと見えてきました。今回は、その話です。
そもそも「i-have-adhd」とは何だったのか
i-have-adhd は、coding assistantの出力を、人間が実際に行動へ移しやすい形へ整えるSkillです。
READMEでは、たとえば次の10個のルールが提示されています。
- 次のアクションを最初に出す
- 複数ステップは番号付きにする
- 最後に具体的なNext Actionを1つ置く
- 余談を抑える
- 毎ターン現在の状態を再提示する
- 時間を具体的に示す
- 進捗・成果を見えるようにする
- エラーを事実ベースで伝える
- 一度に提示するリストを絞る
- 不要な前置き・まとめ・締めの挨拶を減らす
README自身が、
coding assistantが「答えを埋もれさせる」ことを防ぐ
ためのSkillだと説明しています。
前回の記事では、この考え方をそのまま全Agent Teamへコピーするのではなく、抽象度を1段上げて、次の構造にしました。
つまり、Agentの能力を落とすのではなく、人間との境界面を設計するという考え方です。
READMEの最後に書かれていた「Credits」
ここで重要なのが、i-have-adhd のREADMEにあるCreditsです。
そこには、このSkillが J. Russell Ramsay / Anthony L. Rostain『The Adult ADHD Tool Kit』 を「loosely based on」、つまり緩やかに参考にしていることが明記されています。
さらに重要なのが、その次です。作者は、
人間が一日をどう整理するかではなく、
LLMがどう応答すべきかに適応した
という趣旨を明記しています。
ここで、一気につながりました。
私は前回、ADHD向けSkillの考え方をHuman ↔ Agent Interfaceへ応用できるのでは、と考えました。しかし、そのSkill自体がすでに、
成人ADHD向けの実行支援
↓
LLMの応答設計
という変換を行っていたわけです。
では、さらに元を辿ると何があるのか。
『The Adult ADHD Tool Kit』とは
正式タイトルは、The Adult ADHD Tool Kit: Using CBT to Facilitate Coping Inside and Out。著者は、
- J. Russell Ramsay
- Anthony L. Rostain
です。Routledgeから刊行されています。
出版社の説明には、この本の中心的な問題意識がかなり明確に書かれています。成人ADHDでは、
何をしなければならないかは分かっている。
しかし、その意図を実際の行動へ変えることが難しい。
という問題がある。そのため、単に有効な対処法を「知る」だけでは十分ではなく、その対処法を実際に使えるところまで支援する必要がある、という考え方です。
ここで、前回の記事を書いたときには見えていなかった一本の線が出てきました。
「Knowing」と「Doing」の間
i-have-adhd のSKILL.mdには、かなり象徴的な一文があります。
Knowing the answer is not doing the answer.
答えを知っていることと、実行することは同じではない。
SKILL.mdでは、この「分かった」と「やった」の間にある摩擦を減らすため、
- 最初の行動を明確にする
- タスクを小さくする
- Next Actionを1つにする
- 現在地を再提示する
- 進捗を見えるようにする
といったルールが設けられています。
そしてRamsay自身も、成人ADHDに対するCBTについて、Turning Intentions Into Actions というタイトルの論文を書いています。
論文では、成人ADHDにおける問題の一つとして、予定していた行動を実際に実行することの難しさを扱い、CBTによる支援では、この「implementation problem」へ直接働きかけることが重要だと説明されています。
つまり中心にあるのは、次のギャップです。
Intent
「やろう」
↓
Implementation Gap
「分かっているけれど動けない」
↓
Action
「実際にやった」
そして、このギャップはAIエージェントを使う側にもそのまま現れます。
Agentの出力を読んで「言っていることは分かった」となっても、次に自分が何をするかが決まっていなければ、まだ動けていない。
この記事でHuman Interfaceを設計すると言っているのは、結局のところ、KnowingとDoingの間をどう埋めるか、という話です。
本の目次を見ると、さらに分かりやすい
『The Adult ADHD Tool Kit』の目次には、
- To-Do List
- Daily Planner
- Time and Task Management
- Putting the Plan Into Motion
- Motivation, Emotions, and Energy
- Outsourcing Coping Skills
- Data Management
- Environmental Engineering
- Managing the Workplace
- Your Relationship with Technology
などが並んでいます。
個人的に特に興味深かったのは、Putting the Plan Into Motion と Outsourcing Coping Skills です。
計画を立てるだけではなく、実際に動き始める。さらに、すべてを自分自身の頭の中だけで管理しようとせず、対処の仕組みを外部へ持たせる。
ここまで見ると、AIエージェントとの接点がかなり見えやすくなります。
ここからは「設計上の解釈」
ここから先は、本や i-have-adhd が直接そう主張しているわけではありません。私がHuman ↔ Agent Interfaceの設計として読み替えたものです。一対一の対応関係ではない、という前提でお読みください。
その前提で見ると、かなり面白い構造になります。
| Adult ADHD Tool Kit側の考え方 | i-have-adhd | Human ↔ Agent Interfaceとして読むと |
|---|---|---|
| 計画を具体化する | Action First | 最初に実行可能な行動を示す |
| タスクを扱える単位にする | Number multi-step tasks | Agent側で作業単位へ分割する |
| 計画を行動へ移す | One concrete next step | 人間へ判断を戻しすぎない |
| 情報を管理する | Restate state | 人間の記憶だけに状態を持たせない |
| 対処を外部化する | LLMが整理する | 認知負荷の一部をAgent側へ移す |
| 環境を整える | Suppress tangents | 情報環境そのものを整理する |
| 進捗を維持する | Make wins visible | 完了状態を外部化・可視化する |
こう見ると、i-have-adhd は単なる「回答を短くするSkill」ではありません。
むしろ、人間が「理解」から「実行」へ移るときの摩擦を、LLMの出力側から減らすSkillと考えたほうが、本質に近そうです。
AIエージェントが増えると、段取りの仕事が人間側へ残る
AIエージェントが1体なら、
Human
↕
LLM
なので、それほど複雑ではありません。しかしAgent Teamになると、こうなります。
Agent側が賢くなるほど、
- 調査結果
- 実装結果
- レビュー指摘
- QA結果
- リスク
- 未確認事項
- 推奨事項
が増えていきます。情報量としては正しい。しかし、それを全部Human Interfaceへ流すと、「で、私は次に何をすればいい？」という判断が人間側へ残ります。
これでは、タスク分解をAIへ任せたのに、最後のタスク分解だけ人間へ返していることになります。
前回、Next Actionを1つに絞った理由も、今回あらためて説明できます。
悪い例
次に、
・Aを確認してください
・Bを検討してください
・Cも修正できます
・Dについて相談してください
・Eも確認するとよいでしょう
これは情報量としては豊富です。しかし、人間には、
A〜Eを比較
↓
優先順位を判断
↓
最初の行動を決定
という仕事が残っています。そこで、
結論:
レビュー完了
現在地:
Step 4 / 5
成果物:
指摘2件の修正、ビルドログ
未確認:
受け入れ基準Q1
次の一手:
受け入れ基準Q1へ回答する
までAgent側で圧縮する。これがOutput Contractでやりたかったことです。
「短くする」のではなく「Working Setを小さくする」
ここも重要でした。Human ↔ Agent出力契約の目的は、AIの分析を浅くすることではありません。 むしろ逆です。
Agent側では、大量・詳細・網羅的で構いません。必要なレビュー結果、ログ、調査結果、受け入れ試験項目などは、成果物としてすべて残します。
しかし、人間との会話面では、次の6項目へ圧縮します。該当がない項目は省きます。
結論
現在地
重要事項
成果物
未確認
次の一手
つまり、Informationを削るのではなく、Working Setを削るという設計です。
これが前回書いた 網羅性は成果物に、要約は会話に。 という原則につながっています。
Human ↔ Agent Interfaceとして抽象化すると5つにできる
今回、原典まで辿ったことで、前回のOutput Contractをもう少し抽象化できそうだと感じました。私は、次の5つにまとめられると考えています。
1. Action First
説明から始めるのではなく、人間が次に何をすればよいかを明確にする。
2. Externalize State
現在地や完了状態を、人間の記憶だけに持たせない。
Step 3 / 5
レビュー完了
QA未実施
のように、状態を外へ出す。
3. Reduce Working Set
AIが知っている情報を全部表示するのではなく、今、人間が扱う必要のある情報量を絞る。
詳細情報を消すのではありません。成果物側へ置きます。
4. Close the Intention–Action Gap
「理解できる回答」で終わらせず、実際に行動へ移せる回答にする。
「理解した」で終わらせず、「次にこれを実行する」まで変換します。
5. Make Progress Observable
Agent内部で何を考えたかではなく、何が完了し、何が使える状態になったのかをHuman Interfaceへ出す。
「ADHD向けだから有効」とは書かない
i-have-adhd が『The Adult ADHD Tool Kit』を参考にしているからといって、「成人ADHD向けCBTで使われている考え方だから、AIエージェントでも科学的に有効だ」とは言えません。そこには飛躍があります。
また、i-have-adhd のSKILL.mdにはADHDに関する簡略化された説明も含まれています。この記事では、それらの医学的妥当性まで扱いません。
今回取り上げているのはあくまで、実行しやすい情報提示という設計思想が、Human ↔ AI Interfaceにも応用できるのではないかというソフトウェア設計上の話です。
さらに、README自身も「based on」ではなく loosely based on と書いています。
したがって「『The Adult ADHD Tool Kit』をLLMとして実装したSkill」と表現するのも正確ではありません。より正確には、同書を緩やかに参考にし、人間の日常管理ではなくLLMの応答設計へ翻案したSkillです。
モデルの次はHarness。そして、その次にHuman Interfaceがある
最近のAI駆動開発では、
- Model
- Prompt
- Skill
- MCP
- Harness
- Agent Team
と、AI側の仕組みはどんどん高度になっています。しかし、Agent Teamが高度になればなるほど、その能力を人間がどう受け取るのかという問題が大きくなります。
モデルが賢くなる。Harnessが強くなる。Agent Teamが増える。すると最後にボトルネックになる可能性があるのは、
AI
↓
Human Interface
↓
Human
この境界なのかもしれません。
AIエージェントを設計するとき、どうすればAgentをもっと賢くできるかだけでなく、どうすれば、人間がその能力を迷わず使えるかまで設計する。
前回作ったHuman ↔ Agent出力契約を、今回あらためて整理すると、そのための仕組みだったのだと思います。
まとめ
今回辿った流れをまとめると、こうなります。
前回
今回
前回の記事を書いた時点では、i-have-adhd を見つけて、そこからHuman ↔ Agent Output Contractを作った、という2段階の理解でした。今回、原典まで遡ってみると、その手前にもう一段あったことになります。
最初は「ADHD向けの面白いSkillがある」くらいの認識でした。しかし原典まで辿ってみると、その背後には、人間が「分かった」から「実際にやった」へ進むために、情報や環境をどう設計するかという、かなり普遍的なテーマがありました。
そしてAIエージェント時代には、この問いを、Agentの出力を、人間が実際に行動できる形へどう変換するかと読み替えることができます。
AI側は、これからさらに賢くなる。Agent Teamも増える。Harnessも高度になる。
だからこそ、Human Interfaceを設計する。 この一層は、今後ますます重要になっていくのではないかと思います。