事業紹介 事業紹介トップ 経営データ分析基盤 Claude / MCP 導入 育つ業務アプリ 複雑な SaaS を専用 UI に Shopify Plus 移行・拡張 生成AI 活用(Multi AI) SEO / AIO / 広告運用 顧問・アドバイザリ インフラ構築 自社メディア投資・開発
Claude Claude / MCP 総合 Claude Cowork Claude Code 導入支援 Claude Code 使いこなし支援 Claude Design MCP 開発・サーバー構築
Shopify Plus Shopify Plus トップ EC-CUBE からの移行 大手カートからの移行 Shopify 通常プラン EC サイト構築
実績
業界ニュース 業界ニュース トップ AI ニュース └ Claude └ ChatGPT・Codex └ Gemini └ その他 Shopify ニュース SaaS ニュース お知らせ(自社発信)
会社情報 お問い合わせ
2026.08.14

AI Agentが加速させる開発と人間の認知限界——freeeが認知科学から読み解くプロセス設計

記事のサマリー(TL;DR)

  • AI Agentがコード生成を代替しても「認知負債・意図負債」の解消は人間に残り、開発スピードの律速は人間の認知能力になる
  • 分散認知の「社会的分散」がAIへ移転すると暗黙の合意形成が欠落し、チームの共有理解(認知負債)・設計意図(意図負債)が蓄積していく
  • AI時代の開発プロセス設計は「合意形成の総量を絞る」×「1回あたりの認知コストを下げる」という2軸の最適化問題として捉えるべきだ

国内SaaS・受託開発チームが今すぐ問い直すべき合意形成設計

日本の開発組織の多くは「J型企業」的な特性——チーム横断の越境コミュニケーション、ジェネラリスト志向、曖昧な責任境界——を持つ。この構造では、コンウェイの法則に基づく「チーム境界の明確化」(『チームトポロジー』が想定するA型企業的アプローチ)をそのまま適用してもうまく機能しにくい。本記事が示すJ型組織向けの視点、すなわち「責任範囲の分割」ではなく「誰と誰のあいだに厚い共通基盤を構築・維持するか」という配置設計は、日本の開発チームに直接刺さる論点だ。

kintone・Salesforce・freeeのような業務SaaS上に専用UIや自動化を重ねる構成では、複数ロール(PdM・エンジニア・業務担当者)の間のグラウンディングコストが既に高い。そこにAI Agentを投入するとさらに暗黙知が欠落しやすくなるため、「AIとの境界を明示的に契約として定義する」ことが特に重要になる。Claude CodeなどのAI Agentを業務システム連携に使う場合、Agent側に委ねる領域(封じ込め・償却)と人間が合意形成を残す領域を設計段階で区別しておく必要がある。


詳細

人の認知の特性

記憶の多重貯蔵モデル

Atkinson & Shiffrin (1968) による多重貯蔵モデルでは、人間の記憶を「感覚記憶・短期記憶・長期記憶」の3層に分ける。視覚の感覚記憶は1秒以内、聴覚は5秒以内程度。短期記憶の容量はMiller (1956) の「7±2項目」が有名だが、Cowan (2001) 以降は「約4項目」が通説になっている。

ワーキングメモリ

思考の作業場となるのがワーキングメモリ。Baddeley & Hitch (1974) のモデルでは、司令塔の「中央実行系」と、視覚・空間情報を扱う「視空間スケッチパッド」、聴覚・言語情報を扱う「音韻ループ」の3要素で構成される。ラジオを聞きながら本を読むと両方が音韻ループを競合して使うため困難になる一方、ラジオを聞きながら絵を描くと干渉が少ない、という違いが生じる。

選択的注意と非注意性盲目

中央実行系の処理能力には上限があるため、複雑なタスク中は注意対象以外の情報が抑制される(選択的注意)。「Invisible Gorilla」実験で知られるとおり、パス回数を数えることに集中していると、ゴリラの着ぐるみが画面を横切っても気づかない。

チャンキングとエピソードバッファ

10桁の数字列「0318459627」はそのままだと記憶困難だが、「031-8459-627」に分割(チャンキング)するだけで扱いやすくなる。さらに「電話番号」というスキーマと結びつければ記憶負荷は大幅に下がる。Baddeley (2000) はモデルに「エピソードバッファ」を追加し、視空間・音韻の情報と長期記憶を統合して一つの出来事として扱う仕組みを説明した。

スキーマと先行オーガナイザー

「洗濯」というスキーマを提示された後で曖昧な手順説明を読むと、理解・記憶が格段に楽になる(Bransford & Johnson, 1972)。Ausubel (1960, 1968) の「有意味受容学習」では、新情報を既有知識のネットワークに位置づける「先行オーガナイザー」を事前提示することで、受容学習を有意味学習に引き上げられると主張した。

認知負荷の3分類

Sweller (1988) は認知負荷を以下の3種類に分けた。

種類 内容
内在性負荷 対象そのものの複雑さ
外在性負荷 提示の仕方による余分な負荷
学習関連負荷 スキーマ構築に伴う負荷

内在性負荷は提示の工夫では減らせないが、外在性負荷を下げることで全体をワーキングメモリの処理可能範囲に収めることができる。

二重過程理論

カーネマン『ファスト&スロー』で広まったモデルで、思考を「タイプ1(自律的・直感的)」と「タイプ2(ワーキングメモリを使う論理的推論)」に分ける。Wason (1966, 1968) の選択課題では正答率が10%程度にとどまり、多くの人がタイプ1のマッチングバイアスに引きずられる。しかし身近なスキーマに変換したバージョン(Griggs & Cox, 1982)では正答率が7割超に上昇し、スキーマの活性化がタイプ2の熟考を促しやすくすることが示された。


集団としての認知とプロダクト開発

分散認知

Hutchins (1995) は艦船の入港を例に「分散認知」を説明した。左舷・右舷の見張り員がそれぞれ方位を計測して艦橋に伝え、海図にプロットして位置を割り出すという一連の流れは、誰も全体を単独で把握していないにもかかわらず、システム全体として航行タスクを遂行する。分散認知には以下の3軸がある。

  1. 社会的分散:複数の人間の間で知識・判断が分担される
  2. 時間的分散:過去の記録・ドキュメント・設計図が現在の認知活動を支える
  3. 内部-外部の分散:人の内部認知と道具・ソフトウェアなどの外的構造の間で認知が分担される

合意形成とグラウンディングコスト

Clark & Brennan (1991) は、コミュニケーションの成立に「共通基盤(Common Ground)」の形成が必要だと説明した。この共通基盤を構築・維持するプロセス(グラウンディング)には相応のコストがかかり、関係者が増えるほど、専門性の差が大きいほど増大する。

限定合理性とアジャイル

Herbert Simon (1947) の「限定合理性」では、人間は全ての選択肢を列挙して最適解を選ぶことができず、限られた認知の範囲で「十分に満足できる解」を選ぶとした。ウォーターフォール開発は「各フェーズの入力が確定している」という前提を暗に置くが、限定合理性の観点では成り立たない。アジャイル開発は小さいスコープの意思決定サイクルを繰り返すことでこの問題に対応している。


AI Agentを活用した開発で何が変わるのか

AI Agentを開発に導入すると、分散認知の「社会的分散」の一部が「内部-外部の分散」の外部側へ移転する。AI Agentは現時点で以下の制約を持つ。

  • コンテキストウィンドウの制約:Claude Codeでも約1Mトークンが上限。すべての文脈を保持できない
  • 長期記憶の不在:セッションをまたいだ情報の引き継ぎが原則できない。人間の脳が持つ連想的活性化やスキーマ検索の精度を汎用テキスト検索では再現できない
  • 言語化できない情報の不在:非言語情報・感情・クオリアなどを扱えない
  • ヒューリスティクス的判断の困難さ:特定文脈の経験蓄積に基づく直感的判断が現状では難しい

AI Agentは「今この瞬間に与えられた情報から成果物を生成する」能力には優れるが、「チームとしての理解を蓄積し、整合性を維持する」ことは現状できない。

認知負債・意図負債

Storey (2026) は技術的負債に加え、以下の2つの負債概念を提唱した。

負債の種類 内容
認知負債(Cognitive Debt) 「何をしているか」「なぜそうなっているか」の共有理解が失われていく負債
意図負債(Intent Debt) 「何を実現したかったのか」「なぜこの方針を選んだか」というWhyが消失する負債

従来は人間同士の協働の中で暗黙に解消されていた認知負債・意図負債が、AI Agentへの置き換えが進むほど蓄積していく。


認知リソースの最適化問題としてのAI開発プロセス設計

AI Agentがどれだけ成果物生成を高速化しても、人間のレビュー・意思決定はボトルネックとして残る。したがって、AI時代の開発プロセス設計は「人間(の集団)の意思決定速度をいかに上げるか」に帰着する。

認知コストの総計は「合意形成の総量」×「1回あたりの認知コスト」で決まり、最適化の方向性も2軸になる。


合意形成のスコープと粒度の設計

「PRレビューをなくす」議論でよく提示される代替手段は以下の通り。

  • 上流工程へのシフト:コードではなくコンセプト・仕様・受け入れ基準・プロンプトを人間がレビューする
  • レビュータイミングの非同期化・事後化:マージ後に事後レビュー(Human-on-the-loop)、またはfeature branch→main統合時にまとめてレビュー
  • 動作確認・観測による代替:stagingやカナリアリリース+即時ロールバックで振る舞いを確認
  • AIレビューへの置き換え:実装Agentとは別の「敵対的レビューAgent」を使う
  • 決定論的な検証の強化:テスト・型検査・lint・契約検証を厚くし、危険な操作だけ人間へエスカレーション
  • 複数案生成からの選択:複数Agentに並行生成させ人間が選ぶ

ただしこれらの多くは「合意形成の位置を動かす」ものであり、人間が処理すべき総量そのものは変わらない。上流シフトはボトルネックを仕様レビューに移動させるだけで、限定合理性の問題(完璧な仕様を事前に書けるという前提)とも衝突する。

「負債を蓄積させずに合意形成の総量を削減する」経路は以下の3つに整理できる。

経路 内容
圧縮 詳細レイヤーではなく抽象度の高いレイヤーで理解・合意を保持する
封じ込め 安定した境界と機械的検証によって「理解しなくてよい領域」を構造的に作る
償却 短命・使い捨て・低リスクなものへの理解投資をしないことを明示的に決める

これらを適用できない部分が、人間の理解と合意形成を残すべき部分となる。特に「どういうユーザー課題を解こうとしているのか」「プロダクトをどこに向かわせたいのか」という上流判断は、事業環境の変化で頻繁に更新されるため、継続的なグラウンディングの重要性が高い。


チーム構造の設計

コンウェイの法則と逆コンウェイ戦略

Conway (1968)「How Do Committees Invent?」に由来する「コンウェイの法則」は、組織のコミュニケーション構造がシステムのアーキテクチャに反映されるという法則。これを逆手にとり、目指すシステム構造に合わせた組織構造を設計する「逆コンウェイ戦略」が2010年代以降普及した。

『チームトポロジー』の4チームタイプ

スケルトン&パイス『チームトポロジー』は、認知負荷を基準にチーム設計を論じる。価値提供の流れに沿う「ストリームアラインドチーム」を基本単位に、「プラットフォームチーム」「コンプリケイテッド・サブシステムチーム」「イネイブリングチーム」の3タイプがストリームアラインドチームの認知負荷を下げるために存在する。チーム間インタラクションは「コラボレーション(探索期)」→「X-as-a-Service(定常期)」への移行を推奨。

J型企業への適用上の注意

『チームトポロジー』はA型企業(短期雇用・専門的・個人責任)を前提とした設計思想を持つ。日本のJ型企業(終身雇用・非専門的・集団責任)にそのまま適用すると、チーム境界の明確化という根本部分が機能しにくい。

J型企業の場合、チーム構造の設計は「責任範囲の分割」ではなく、「誰と誰のあいだにどのくらい厚い共通基盤を構築・維持するか」という配置設計として捉え直す方が現実に合致する。厚い共通基盤が張られた相手とのあいだでは合意形成が安価に行え、薄い相手とのあいだでは大きなグラウンディングコストがかかるという構造は変わらない。

人間とAI Agentの境界については、J型企業的な暗黙知共有はAI Agentが参加できないため、境界を特に明示的に定義する必要がある(前述の「封じ込め」「償却」の領域明示)。


レビュー可能性の高い情報デザイン

AI Agentが高速に成果物を生成しても、人間によるレビュー・意思決定は残る。このレビューはタイプ2の熟考(ワーキングメモリを要する論理的推論)が必要となるため、外在性負荷をいかに下げるかが重要になる。

Clark, Nguyen & Sweller (2006)『Efficiency in Learning』やMayer (2020)『Multimedia Learning』の認知負荷理論から引き出せる主な設計原則は以下の通り。

  • 視覚情報と音声(または言語)情報を組み合わせて2チャネルに分散させる
  • 矢印・ハイライト・見出しで重要箇所に注意を誘導する
  • 学習目標に関係しない情報は削除する
  • 関連する図とテキストを空間的に近接させる
  • 複雑な内容は構成要素を先に提示してから全体の相互作用に進む
  • 先行オーガナイザーで全体像を示す

これらをAI生成物のレビューに適用するため、freeeのエンジニアは reviewabilize というAgent skillを開発した(GitHub公開)。主な設計方針は次の通り。

  • セグメント化:レビュー単位を「文書」ではなく「判断」の粒度に分割し、1項目が1論点に対する1問いになるように構成
  • 提示の順序:影響範囲の大きい判断から順に並べ、判断項目の全体像を先頭で先行オーガナイザーとして提示
  • 図示:HTML/SVGなどで図を提示し、マルチメディアの2チャネルで処理できるようにする
  • 既有知識への調整:誰がレビューするか・その既有知識は何かを成果物生成前に確認し、不要な部分は読み飛ばせる形で示す

まとめ

AI Agentの活用がどれだけ進んでも、認知負債・意図負債の解消に関わる部分を人間から置き換えることは現状できず、開発スピードは最終的に人間の認知が律速になる。AI時代の開発プロセス設計は、人間の認知リソースと分散認知リソースの配分最適化問題として捉えるべきだ。

最適化の2軸——「合意形成の総量を絞る(圧縮・封じ込め・償却)」と「1回あたりの認知コストを下げる(チーム構造設計・レビュー可能性の高い情報デザイン)」——は、それぞれが独立に効く。ただし、この設計自体も限定合理性の問題を免れず、AIモデルの進化や事業環境の変化に合わせて漸進的に更新し続けるプロセス体制が求められる。

freeeの社内ではAI Agentを活用した開発プロセスの整備が進行中で、reviewabilizeの組み込み検証も続いている。