強い AI エージェント（Claude / ChatGPT / Gemini 等）が MCP 経由で日常的にプロダクトを操作する時代では、能力を GUI に積むほど、エージェントから使う主経路と二重化し、保守コストも人間ユーザーの操作負担も増える。プロダクトの比重をエージェント側に置き、GUI は薄く保つ。

判断基準

• 能力（生成・編集・分類・検索などの「やる」操作）はエージェント / MCP 側に寄せ、GUI には積まない。
• 人間向け GUI は作業場ではなく**「確認する箱」**＝閲覧・確認・最終承認の薄い層に留める。
• GUI に機能を足したくなったら、まず「MCP ツール＋エージェント運用（プロンプト / スキル）で満たせないか」を問う。満たせるなら GUI には足さない。
• human-in-the-loop（レビュー・承認）も、GUI 専用機能を作る前に、エージェント運用（例: スケジュールで『案だけ出す』→人が確認→保存ツールを呼ぶ）で満たせないか先に検討する。

なぜ

agent-first 前提では主たる利用面は MCP。GUI に能力を二重実装すると、保守コストと利用者の認知負担が両方増える。GUI を薄い確認層に保てば、能力追加は MCP ツール / スキルの追加に集約でき、エージェント側と人間側の双方の体験が軽くなる。

適用条件・境界

• 「人が見て決める」部分（公開可否のレビュー、真正性の確認など）は GUI に残す価値がある。だから箱をゼロにはしない。
• agent-first を前提に置けるプロダクト限定。非エンジニア主体・規制 / 監査で GUI が主経路になる前提のプロダクトには当てはまらない。

落とし穴

• 「レビュー体験が要る」→反射的に GUI 機能を作る、は agent-first 文脈では過剰になりやすい。まず運用（スケジュールのプロンプトを『案だけ』にする等）で満たせないかを先に問う。

検証

新機能要望に対し、「MCP ツール＋エージェント運用では代替できず、かつ人が見て決める必要がある」場合だけ GUI に実装されているか。GUI が作業場化していないかを定期的に点検する。