書評|AI氣道

AI×アーキテクト 書評|元木大介・熊井悠の全12章を要約し経営者向けに解説

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん(@passion_tanaka)です。

2026年10月27日、技術評論社から『AI×アーキテクト〜「複雑性・不確実性」を構造で受け止める〜』が発売されました。著者は元木大介さんと熊井悠さんです。

Kindleで買いました。

本が届いて、さっそく、まえがきから最後まで全部読んでしまいましたw

読み終えて、まず思ったのは「これは必読」ということです!

この記事では、全12章を要約し経営者向けに章の順で解説します。そのうえで、経営者がAIに仕事を任せる前にやることを、本の言葉で組み立てます。

この記事の要点

  • 本の背骨は「生成と検証の非対称」と「急がば回れ」。作る速さに、確かめる時間が追いつかない。
  • アーキテクトは肩書きではなく働き。AIが持てない「全体の文脈」を設計し、維持する人のこと。
  • AIに任せる前にやるのは、守りの配置を先に作ること。評価から始めれば迷いません。
任せる前に守りの配置を作る
図1|任せる前に守りの配置を作る
元木大介・熊井悠『AI×アーキテクト〜「複雑性・不確実性」を構造で受け止める〜』の表紙

AI×アーキテクト〜「複雑性・不確実性」を構造で受け止める〜

元木大介・熊井悠 著

Amazonで本書を見る

※Amazonアソシエイトのリンクです。リンク経由でご購入いただくと、当サイトに紹介料が入ります。

なぜ今『AI×アーキテクト』を紹介するのか|共著者の元木大介さんは私のAIの師匠

共著者のひとり、元木大介さんが私のAIの師匠
図2|共著者のひとり、元木大介さんが私のAIの師匠

理由はシンプルです。

共著者のひとり、元木大介さんが私のAIの師匠だからです!もう一人の著者、熊井悠さんは第4〜7章の現場の実践を書いています。

元木さんは、天下一AI魔導会の優勝者です。優勝した作品はゾルトラーク。

2026年10月26日の夜、GPTs研究会の9,000名記念コラボLIVEがありました。出演は元木さん、AI国王こと純さん、ただっちこと多田啓二さん、そして私です(LIVEのアーカイブ)。

本の発売前日のLIVEで、元木さんは本の中身をスライドにして見せてくれました。書籍は文字ばかりで頭に入りにくいから、と。

最初は開発寄りで書き進めていて、編集者さんと話す中で一般向けに切り替えたそうです。とくに第1章と第2章は柔らかい内容にした、とも話していました。

入口が柔らかいなら、技術の言葉に慣れていない経営者にも、最初の2章は開いてもらえる。私はそこに、この本をブログで紹介する意味があると考えています。

LIVEの締めで、私は「本質的な話が聞けた」と話し、本を「予約させていただいた」と伝えました。続けて、この本をまた読んで解説をLIVEでやりたい、感想のシェアもGPTs研究会で特集したい、と話しています。

LIVEでの解説の前に、まずこのブログで全章を解説します!

師匠の本だからといって、持ち上げるだけの記事にはしません。読む人を選ぶ所も、まとめで書きます。

本の背骨は「生成と検証の非対称」と「急がば回れ」

アーキテクトの3本柱
図3|アーキテクトの3本柱

12章もある本ですが、背骨は1本です。まえがきの、この一文に集まっています。

生成する速度は、桁違いに加速しました。しかし、生み出されたものを確かめる人間の時間は、1秒も縮まっていません。

『AI×アーキテクト』まえがき

AIは、文章もコードも画像も一瞬で出します。でも、それが正しいかを確かめるのは人です。

人が読む速さも、理解が沈む時間も、この10年でほとんど変わっていません。本はこの開き続ける差を「生成と検証の非対称」と呼び、全章で断りなしに使う言葉に据えます。

AIで速くなったのは作る側だけ、という見方もできるんですよね。確かめる側の時間が同じなら、作るほど、まだ誰も確かめていない物が手元に積もっていきます。

城は一晩で建つ。けれど城壁は一晩では築けない。

この差にどう向き合うか。本が選んだのは、室町時代の連歌師・宗長の作とも伝わる歌です。

「もののふの矢橋の船は速けれど急がば回れ瀬田の長橋」

琵琶湖を渡し船で行けば速い。けれど比叡おろしの突風が吹くと、速いはずの船が、いつ着くか分からない船になる。だから瀬田の長橋を回る。本はこの一首を、全12章を貫く背骨にしています。

回り道とは、設計のことです。

元木さんもLIVEで同じ話をしていました。AIを使うほど枝葉が増えて、頭がごちゃごちゃになる。だから幹を固めて育てる。大量の情報に慌てる時こそ、1回回り道してでも橋を作っておく。それがこの本のコンセプトだ、と。

あ、ここでの「急がば回れ」は、遅く進めという話ではないんですね。突風が吹いても向こう岸に着ける道を、先に持っておく話なんだと、今の私は考えています。

では、橋を架けるのは誰か。本の答えがアーキテクトです!

AIが持てない全体の文脈を設計し、維持する人。肩書きではなく働きなので、エンジニアでも企画の人でも経営者でも担えます。

アーキテクトの3本柱は、ルールの設計、境界の設計、フィードバックループの設計です。出力を生む型を決める。人とAIの持ち場に線を引く。起きた問題をその場の修正で終わらせず、ルールと境界へ戻す。

この背骨を持って、各章を読んでいきます。

『AI×アーキテクト』全12章の要約と解説|まえがきからあとがきまで

本は5部構成
図4|本は5部構成

ここからは、まえがき、全12章、あとがきの順に、一度だけ全容を解説します。

本は5部構成です。第1〜3章が土台、第4〜7章が現場の実践、第8〜10章が自律を支える技術基盤、第11章が組織と事業、第12章が経済と社会。第4〜7章は熊井悠さん、ほかの章は元木大介さんの担当です。

まえがき|飛べない魚に届いた翼

まえがきは、元木さん自身の話から始まります。

話すことも、暗記も、文章も、絵も、プログラミングも、自分の手で作ることにことごとく行き詰まっていた。映像で考える元木さんにとって、文章やコードは、海の魚が無理に空を飛ぼうとするようなものだった、と。

2023年、生成AIという「機械仕掛けの翼」が届きます。書けなかった人が出したプロダクトが、世界中で使われました。魚が空を飛んだんです!

魚が空を飛んだ
図5|魚が空を飛んだ

ところが熱狂のあとに、底冷えのする静けさが来る。最新モデルに飛び乗って走り続けている間だけ、飛べている。その熱狂の中で、朝の焦燥と夕方の破綻が起きる。その正体として出てくるのが、生成と検証の非対称です。

飛べなかった魚の話から始まるから、後ろの章の型が、できる人の飾りではなく、行き詰まった人の足場として読める。今の私はそう受け取っています。

立場の表明もあります。元木さんは、人がAIを支配するのか、AIが人を支配するのか、という問いの立て方そのものに反対します。信じるのは、人とAIが融け合った世界。無数の人と無数のAIを律するのは、命令ではなく構造だと書きます。

第1章 検証が生成に追いつかない AI時代の課題

第1章は、朝の焦燥と夕方の破綻を、同じ1つの構造を内側と外側から見たものだと言い切ります。

壊れているのは速さではありません。作る力と確かめる力の釣り合いです。

手間がかかった時代は、作る過程そのものが検問でした。時間がかかるから、作る前に考えた。生成AIは、この隠れた品質フィルターを関所ごと取り払いました。

うーん、手間が検問だった、という見方は重いです。面倒だった時間に、品質が守られていた。面倒を消すと、その守りも一緒に消えてしまう。

作る力と確かめる力の釣り合い
図6|作る力と確かめる力の釣り合い

そこで起きる失敗として、本は「作れたつもりの罠」「木を見て森を見ず」「音のしない劣化」を挙げます。

そこで起きる失敗
図7|そこで起きる失敗

怖いのは最後です。体裁は整っていて、通して読んでも問題がない。水面下で方針の揺れや見落とした前提が積もり、改訂の時に一気に表に出ます。

なぜAIだけでは防げないのか。LLMは「この文脈の次には何が来そうか」を予測するよう訓練されていて、「何が正しいか」を判断するようには訓練されていないからです。組織だけのルールや、過去の失敗から刻まれた判断基準は、文書に書かれていない。学習しようがありません。

アーキテクトとは、AIが持てない「全体の文脈」を設計し、維持する人。

『AI×アーキテクト』第1章

この定義が、本全体の物差しになります。

後半は『孫子』です。彼を知り己を知れば百戦殆うからず。彼はAIの性質、己は目の前の仕事の性質。そこから第一原則が置かれます。守りの配置を整えて生成を解き放つ。

見極めの問いは、このタスクには、生成の速さに釣り合う守りの配置が先にあるか。あれば大胆に任せる。なければ範囲を絞るのではなく、先に配置を作る。慎重にやれという話ではなく、速さを使い切るための原則です。

私がこの章で一番大事だと考えるのは、ここです。止めるための原則ではなく、任せるための原則として書かれているからです。

判断に使うのが3つの評価軸です。文脈の広さ、不確実性の扱い、関与の深さ。

判断に使うのが3つの評価軸
図8|判断に使うのが3つの評価軸

コピー案の叩き台なら、10案中3案が使えれば十分。揺らぎが長所になります。決済金額や契約条項は、一つの誤りも許されない。関与は補助、協業、自律実行と段階があり、上げる理由は「AIの性能が上がったから」ではなく「守りの配置が育ったから」です。

城の配置図のたとえも分かりやすいですよ。石垣を積む職人が制作のAI、関所の門番が点検のAI。石垣職人に、自分が積んだ石垣を見回らせない。作るAIと確かめるAIを分けて、人は最終承認に絞ります。

作るAIと確かめるAIを分けて、人は最終承認に絞ります
図9|作るAIと確かめるAIを分けて、人は最終承認に絞ります

私の場合|「どんどん委ねる」と言うほど、先に要るもの

LIVEの冒頭、私は自己紹介でこう話しています。

「社長無人化計画というのをやっておりまして、AIにどんどん仕事を委ねてですね、人間はよりワクワク夢中に、遊び探求するという生き方をですね、日々実践しながら皆さんにもお伝えしております」

AIに仕事を委ねて、人はワクワク夢中に遊び探求する。これが私の選んだ生き方です。

第1章の問いを、この生き方に当てるとどうなるか。「どんどん」は速さです。その速さに釣り合う守りの配置が、先にあるか。本の問いは、そのまま私の社長無人化計画への問いになります。

第2章 変化に動じないアーキテクトの素養

第2章は、システムより先に人の側を整える章です。ツールは1年で入れ替わる。でも型は残ります。

型とは、繰り返し使えるようになった判断の雛形。型は種、アーキテクチャは木、アーキテクトは庭師です。手渡される型は、思考、問題解決、創作、布陣、関係、稽古の6つ。本書は自らを、守破離の「守」の本と位置づけます。型を持たない自由は、自在ではなく、ただの漂流だ、と。

型を持たない自由は漂流。この一言のおかげで、自由と型を対立させずに読めます。型があるから、外れた時に外れたと分かるんですよね。

思考の型で効くのは「発散はAIに、収束はアーキテクトに」。小さく作って足すのではなく、多めに作って引く。ただし設計の手綱だけは手放さない。

問題解決の型はポリアの4段階、理解、計画、実行、振り返りです。AIが劇的に速くしたのは実行だけ。理解と計画を飛ばした丸投げを、本は「間違った問題の正しい解の量産」と呼びます。

AIが劇的に速くしたのは実行だけ
図10|AIが劇的に速くしたのは実行だけ

創作の型は「削り出し」です!

白紙に描き足すのではなく、荒削りの塊をAIに出させて、余分を削る。何を残し何を落とすかの審美眼が、そのまま仕事の質になります。夏目漱石『夢十夜』の運慶の話から、モデルの重みとデータに無いものは、どれだけプロンプトを磨いても生成できないと読むくだりは、この章の白眉です。

布陣の型には手順があります。戦力の癖を知る。地形を読む。陣形を選ぶ。持ち場を決める。摩擦に備える。接触したあとに組み替える。「モデルは借りられますが、データは借りられません」という一文も、ここで出てきます。

布陣の型には手順があります
図11|布陣の型には手順があります

関係の型で出てくるのが、ドーナツ型です。

避けたいのは逆ドーナツ。人が最前線で顧客対応をし、裏でAIが内部作業をこなす配置です。創造的でない反復とストレスを、人が背負い続けます。あるべきは、顧客と接する外縁にAI、中核にもAI、その間の中間帯に人を置く形です。

関係の型で出てくるのが、ドーナツ型
図12|関係の型で出てくるのが、ドーナツ型

章末で、6つの型の底にあるものが明かされます。勾配を登ることです。何を良しとするかを決め、今の位置を照らし、少しでも良くなる方へ一歩出す。

AIは、人が一生かけた山を一晩で登りきります。そして登りきったとたん、次の山が見えなくなる。まえがきの静けさは、ここから来ていました。

AI時代に問われているのは、速さではなく、どの山に登るかです。

『AI×アーキテクト』第2章

物差しを握るのは最後まで人。ただし物差しそのものを目的にした瞬間に狂う、というグッドハートの法則まで添えてあります。

私の場合|師匠から習った側が、師匠の「守」の本を開く

LIVEの自己紹介で、私は元木さんを、まさに私のAIの師匠だと紹介しました。

元木さんからAIを習って、今の私があります。

第2章は、この本を「守」の本だと言います。型を身につける段階の本です。

習ってきた相手が、自分の型を一冊にまとめた。それを習った側が読む。守破離の言葉でいえば、守の稽古をあらためて受ける読書です。

第3章 古典から始める8つのアーキテクチャスタイル

第3章で、技術の色が一段濃くなります。

家に在来工法やツーバイフォーという工法の名前があるように、ソフトウェアにも名前の付いた骨組みがあります。それが8つのアーキテクチャスタイルです。下敷きは、Mark RichardsとNeal Fordの『ソフトウェアアーキテクチャの基礎』。

レイヤード、パイプライン、イベント駆動、スペースベース、マイクロカーネル、マイクロサービス、サービスベース、サービス指向。名前だけ並ぶと難しく見えますよね。

スタイル名を言えば、構造の制約が数語で伝わる
図13|スタイル名を言えば、構造の制約が数語で伝わる

芯は、名前を付ける効用です。料理人に「ここは湯煎で」と言えば伝わるように、スタイル名を言えば、構造の制約が数語で伝わる。宣言は、設計判断の記録と、AIが毎回読み返す開発ルールのファイルの2か所に、同じ文面で置きます。

経営者の仕事に近い例が、本の中にあります。社内の経費精算の問い合わせに、AIで自動で答えたい場合です。

根拠は経費規程という閉じた文書なので、文脈は狭い。誤案内は避けたいので、根拠の提示は必須。定型の質問はAIに任せ、判断が割れる質問だけ経理担当へ。答えは、レイヤードを背骨にパイプラインを足す構成で十分です。エージェントの群れは要りません。

この程度で十分だと、自信を持って言い切れる。それがスタイルを知る効用だ、と本は書きます。

あ、知識は大きく作るためだけでなく、小さく止めるためにも要るんですね。群れが要らない所で群れを組まない判断も、設計の一つだと私は考えます。

パイプラインの節には、怖い数字もあります。各段の成功率が99%でも、10段つなげば全体はおよそ90%まで落ちる。人の承認は、社外への送信や支払いのような取り返しのつかない段の直前に絞ります。全段に置くと、人は承認ボタンを押すだけの係になります。

各段の成功率が99%でも
図14|各段の成功率が99%でも

組織の話で刺さるのは、サービス指向の節です。

受付が混みすぎれば、人は裏口から入ります。

『AI×アーキテクト』第3章

AIの利用ルールが厳しすぎると、現場は個人契約のAIへ流れます。シャドーAIです。統制の目的は利用を堰き止めることではなく、承認済みの道を迂回路より便利にすること。あなたが社内のAIルールを作る立場なら、この節だけでも読む価値があります!

第4章 人の役割が変わる 従来開発とAI駆動開発

第4章から第7章は熊井悠さんの担当で、開発の現場の手触りが、ぐっと濃くなります。

まず、ウォーターフォールとアジャイルが整理されます。熊井さんは両者を、手順の違いではなく、リスクをいつ引き受けるかという思想の違いだとまとめます。

ウォーターフォールの原型とされる1970年のロイスの論文で、ロイス自身は逐次の方式を危ういと述べ、反復と試作を勧めていた。この史実の紹介も面白いです。

そのうえでAI駆動開発を、生成AIを開発プロセスの全段階に組み込むやり方だと定義します。開発ツールとしてAIを使うだけ、という意味ではありません。

大事なのは、工程の並びが変わらないこと。要求・要件定義、設計、実装、デリバリ・運用の順は残り、変わるのは各工程の進め方です。AIの出力は毎回少しずつ違う。それを不具合ではなく、本質的な性質として扱います。

工程の並びが変わらない
図15|工程の並びが変わらない

経営者に一番届いてほしいのは、ベースラインの話です。

AIを入れる前に、今の数字を取っておく。ベースラインのない比較は、どれだけ丁寧に測っても印象論になる、と熊井さんは書きます。生成量を指標にしない。数字を個人の評価に使わない。測られる側は数字に合わせて動き、最初に削られるのがレビューの丁寧さだからです。

「導入したら良くなった気がする」で終わらせないための、地味だけれど効く一手だと思います。入れる前の数字は、後から取り戻せないからです。

第5章 人とAIの境界を引く工程設計

第5章の問いは、人とAIの担当をどこで分けるかです。

要件定義の線引きが鮮やかです。要求定義は、そもそも何を作るかを決める工程。要件定義は、決まった要求を網羅して文書に固定する工程。前者は人に残り、後者でAIが一番力を発揮します。

要求定義
図16|要求定義

AIは選択肢を広げ、見落としを指摘し、根拠を集めますが、どれを選ぶかを引き受けることはできません。

『AI×アーキテクト』第5章

例は、問い合わせ対応の工数を減らしたい、という話です。過去の履歴から回答案を出すのか。よくある質問を自動で振り分けるのか。そもそも問い合わせが起きない導線に作り替えるのか。これを選ぶのが要求定義です。

線を引かずにAIへ任せると、選んでいないはずの案の要件だけが精緻に積み上がる。誰も判断していない仕様の出来上がりです。

AIが速いほど、選んでいない案まで立派に育つ。速さが、決めていないことを見えにくくするのだと思います。だから何を作るかの一点だけは、人が先に決めておく。私はこの章をそう読んでいます。

設計では、AIに渡す範囲を小さく保ちます。在庫の引き当て、在庫の更新、担当者への通知を1ファイルに混ぜると、通知の文面を直したいだけなのに、AIが引き当ての条件まで書き換える。分けておけば、渡すのは通知だけで済みます。

運用では、提案と承認と実行を分けます。AIは状況を整理し、仮説を出す。実行して責任を持つのは、権限のある人です。

提案と承認と実行を分けます
図17|提案と承認と実行を分けます

第6章 評価から始める 新規開発の実践

第6章は、新しくAIを組み込むプロダクトをゼロから作る章です。テーマは、今しかできないことを見極めること。

最初の例が分かりやすいです。過去の稟議書から、新しい申請の可否をAIに判定させたい。文書は十分ある。けれど、否決された案件の記録がほとんど無い。承認されたものしか文書に残らない運用だったからです。判断は、このままでは着手しない。まず否決の記録を貯めるところから。

できるかどうかを技術で見極められる人が止めなければ、誰も止めない。この章の空気がよく出ています。

設計の節では、作り直せる場所と作り直せない場所を分けます。プロンプトやモデルの選定は、動かしながら決めてよい。蓄えるデータの形、外部と交わす約束、利用者に与える権限の境界、生成物と判断の記録は、先に決めきる。

作り直せる場所と作り直せない場所を分けます
図18|作り直せる場所と作り直せない場所を分けます

では、何から作るのか。

評価の経路を先に、環境をその次に、デプロイの骨格をその次に、機能を最後に置きます。

『AI×アーキテクト』第6章

機能は、いつでも足せます。評価の経路は、後から敷けない。動くものを先に作り、評価を後回しにしたプロジェクトは、半年後に「前より良くなったのか」に答えられなくなります。新規開発で一番よく見る失敗だそうです。

評価の経路を先に
図19|評価の経路を先に

うーん、これは開発に限らない話だと私は考えています。新しい施策を始める時も、良くなったかを何で見るかを先に決めておかないと、半年後に同じ問いへ答えられなくなります。

自律性の線引きも明快です! フローチャートに描けるなら、固定の処理として書く。描けないから委ねるのであって、描けるのに委ねるのは設計の放棄だ、と。

第7章 制約を資産に変える 既存開発の実践

第7章は、すでに動いているシステムの上にAIを入れる話です。稼働中のシステムも、決まった契約も、根付いた開発文化も、動かせない制約であると同時に、AIに渡せる文脈という資産でもある。タイトルどおりの中身です。

熊井さんは、自社サービス開発、システム受託開発、社内業務システム開発、人材派遣・SES事業に分けて、引く線を変えます。自社サービスなら、どこで止めるかを先に決めるブレーキの設計。受託なら、技術の線を契約の言葉に訳すこと。

社内業務の節の一文は、中小企業にもそのまま当てはまります。読めない資産を読める資産に変えることが、最初の投資だ。古いシステムのコードをAIに読ませ、業務の流れ、画面の役割、データの形を、普通の言葉の文書に起こし直します。

SESの節では、顧客の現場で課題を決める前線と、自社で生成や品質保証やナレッジ管理を担う後方を分けます。何もしなければ、案件が終わった時点で自社には何も残らない。知見の持ち主を、個人から組織へ移すための分け方です。

個人から組織へ
図20|個人から組織へ

人が入れ替わっても残る物を先に作る。この発想は、AIの前からある経営の宿題にもそのまま重なると思います。

第8章 自律の線を固めるエージェントアーキテクチャ

第8章から第10章は、技術の密度が一気に上がります。

冒頭の場面がうまいんですよね。金曜の夜、エージェントに「週明けまでに、この機能を仕上げておいて」と頼んで帰る。月曜の朝、何百ものファイルが書き換わり、テストはすべて通っている。けれど、誰も頼んでいない変更が一行だけ紛れ込んでいる。

単発のAI呼び出しは電卓に似ています。入力に出力を返すだけ。エージェントは違います。観て、判断し、道具で外へ働きかけ、また観る。次に何をするかまで、自分で決めながら回します。

単発のAI呼び出しは電卓に似ています
図21|単発のAI呼び出しは電卓に似ています

だから、自律性は高ければよいとはならない。

1段上がるごとに予測しにくくなり、確かめる手間が増えます。本の数字では、1ステップ95%の精度でも、20ステップ続けると最後まで正しく走る確率は約36%。必要最小限の自律性を選ぶのが、アーキテクトの仕事です。

必要最小限の自律性を選ぶ
図22|必要最小限の自律性を選ぶ

経営者の仕事に引き寄せるなら、この一文です。

「削除しないでください」と頼むより、削除ツールを渡さないほうが確実です。

『AI×アーキテクト』第8章

あなたが人に仕事を頼む時も、同じですよね! お願いで縛るより、触れられる範囲を先に決めておく。本は、参照は自由、戻せる変更は事後に確認、本番への反映や外部への送信やデータの削除は人が事前に承認、という分け方を示します。

承認が形だけになる怖さも書かれています。承認までの平均が数秒なら、それは検討ではなくクリック。判断できる材料を渡さない承認は、形だけの儀式になる、と。

第9章 AIの群れを律するスウォーム技術

第9章は、AIを何十体、何百体と並べて動かす話です。本はこれをスウォーム技術と呼びます。

冒頭は人類の歴史です。熱力学、統計力学、経済学、組織論。膨大な数を扱う知恵は、規模が大きくなるほど、一人ひとりの顔ではなく全体の仕組みを見る方向へ進んできました。元木さんの見立てでは、スウォームは今、分子を知らないまま蒸気機関を改良していた熱力学の段階にいます。

自分の仕事なら何にあたるか。本の例が分かりやすいです。

毎晩の全件の分類や要約は、手順をプログラム側が握るAPI連携で回す。クレームが急に増えた原因の調査のように、手順を書き切れない仕事はエージェントに任せる。エージェントが答えを出した手順は、API連携へ昇格させて固定します。

数を増やすと、壁にぶつかります。本は壁を4つ挙げていて、たとえば並列にできない部分が残る時間の壁、利用枠(レートリミット)の壁、計算資源の壁です。ある壁をよけると次の壁が現れ、詰まる場所が移っていく。しかも利用枠は組織全体で一つのバケツを分け合う形なので、1体の暴走が群れ全体の枠を飲み干します。

利用枠は組織全体で一つのバケツを分け合う
図23|利用枠は組織全体で一つのバケツを分け合う

プロンプトの工夫は1体を賢くしますが、ハーネスの設計は千体を統率します。

『AI×アーキテクト』第9章

ハーネスとは、エージェントを外から支える骨組みです。仕事の投入、並列度の制御、再試行と打ち切り、成果物の回収、評価と選抜、記録の回収までを束ねます。

ハーネスとは、エージェントを外から支える骨組み
図24|ハーネスとは、エージェントを外から支える骨組み

1体を賢くする工夫と、千体をまとめる仕組みは別物です。あ、数を増やす話は、結局は仕組みの話なんだと、今の私は受け取っています。

合議の節も面白いです。AIに採点させる時、同じ癖の審査員を10体並べても実効の票は増えない。数より多様性を取る。合議は品質を作らず、作られた品質を正しく推定して選ぶだけです。

最後の相図は、元木さんの見立てとして書かれています。計画の強さと連携の強さの2軸で群れを見ると、連携を強めたある境目で完遂率が一段で変わる。水が沸くような相転移が起きている、と元木さんは見ています。

私の場合|LIVEで元木さんに聞いた、アカウントの切り替え

LIVEの後半、私は元木さんに質問しました。

私は何アカウントも使っています。複数のアカウントを登録しておいて、自動で切り替えられるのか。

元木さんは、複数のプランを裏側で切り替える形を説明してくれました。自動で切り替わる仕組みは、私から今後の要望として伝えています。私が何アカウントも使っている噂を聞いていて、頭の片隅で私を想像しながら作っていた、とも話してくれました。

第9章を開くと、あの質問の位置が分かります。群れを大きくした時の、利用枠の壁です。本は、増やす前に、まず減らして使う順番を勧めます。アカウントを足す前に、今の群れがどこで詰まっているかを測る。第9章は、その順番まで教えてくれます。

第10章 AIが守る運用とAIに渡すデータ基盤

第10章は、作ったあとの話です。車が納車の日から傷み始めるように、AIのシステムもリリース直後から揺らぎにさらされます。

一番厄介な障害は、エラーを出さないことです。正常に応答したまま、もっともらしく間違い続ける。本の例では、問い合わせを振り分けるAIの精度が、特定のカテゴリだけ落ちます。コードは何も変えていない。調べると、週末に依存先のモデルが更新されていた。あるいは新製品の発売で、問い合わせの言葉づかいが変わっていた。

エラーを出さない
図25|エラーを出さない

だから運用は、開発の後始末ではなく設計の主役になります。正解つきのデータで変更のたびに確かめ、本番に出したあとも抜き取りで見張る。避難経路は平時に試す。使ったことのない避難経路は、本番では機能しません。

うーん、壊れても音が鳴らないなら、鳴る仕組みを先に置いておくしかありません。第1章の「音のしない劣化」が、ここで運用の言葉になっています。

この章は、開発の外にも広がります。顧客ごとに文面を作るキャンペーンメールなら、送る前に禁止表現やトーンの関門を通す。送ったあとは開封率や解約率を追う。開封率がじわじわ落ちるのは、音のしない劣化のビジネス版です。

キャンペーンメール
図26|キャンペーンメール

後半はデータ基盤です。同じモデルで問い合わせ対応のAIを作っても、過去10年分の対応履歴を症状ごとに検索できる形で渡した側は、具体的に答えられる。公開マニュアルのPDFを流し込んだだけの側は、言い換えにとどまる。

誰でも同じモデルを借りられる今、差を生むのは自社の文脈を抱えたデータです! AIの回答が悪いと言われた時、原因はモデルよりデータ側にあることが多い、とも本は書きます。

第11章 人の持ち場を決める AI駆動の組織と事業

第11章は、経営者に一番近い章です。章を貫く問いは一行。AIがすべてをやるなら、人は何をするのか。

入口は産業革命のたとえです。蒸気機関車から自動車、航空機、ロケットへと機械が進んでも、全人類がロケットの操縦士を目指したわけではない。実際には、機械を作る人と運転する人が分かれ、多くの人は使う側に回りました。全員を頂上へ向かわせるのではなく、適材適所に置く。

全人類がロケットの操縦士を目指したわけではない
図27|全人類がロケットの操縦士を目指したわけではない

人に残る仕事は、目的を決める、止める、文脈を供給する、組み合わせを設計する、です。

「AIを導入したのに人が楽にならない」の原因は、性能ではなく配置です。

『AI×アーキテクト』第11章

外縁と中核をAIが受け持ち、中間帯の人が検証と例外の判断と文脈の調整を担う。第2章のドーナツ型が、ここで職務設計になります。

測ってはいけない指標の話も、そのまま経営に効きます。利用回数、生成した文書の量、研修の受講時間、導入したツールの数、アンケートの自己申告。目標にした瞬間、数字だけが伸びる。測るべきは、AIの出力の誤りを見抜き、根拠を挙げて差し戻せる力です。もっともらしい誤りを混ぜて見抜けるか試す、ミューテーションテストの人間版まで書かれています。

後半はマーケティング、営業、カスタマーサクセスです。新製品の紹介記事をAIで30本出した翌朝、1本の比較表だけ競合の仕様が一世代前のままだった。記事は取り下げられても、スクリーンショットは取り下げられない。評判は買い戻せない、という話です。

「文脈を持たない賢いモデルは、賢い他人にすぎません」という一文も、この章です。

LIVEで元木さんは、仕事を山登りにたとえていました。仲間と頂上を目指すのが楽しいのに、AIというヘリコプターが出てきた。会社は早くゴールしてほしい。すると楽しみが消えて、虚しさが残る。だから目標を、ヘリコプターでも届かない所まで大きくする。月へ行くロケットにすれば、ベテランも若手も全員で楽しめる、と。

実は元木さん自身も、100体のAIを動かせた段階で何でも秒で終わり、何をすればいいか分からなくなった時期があったそうです。

ただっちは締めで「目標ちっちゃくしてたなと思った」と話していました。

目標を大きくするという答えは、第2章の「どの山に登るか」とそのまま重なります。AIが山を一晩で登るなら、人が決めるのは次の山の高さ。今の私はそう考えています。

私の場合|嫌いなこと苦手なことは委ねて、好きな料理は自分で作る

同じLIVEで、私はこう話しました。

AIには、自分が嫌いなことや苦手なことをどんどん委ねる。好きなことまでAIにやらせることはない。料理が好きだから、料理ロボットが出ても、自分で作りたい。

第11章の問いに、私なりに引いた線です。

本の言う人の持ち場は、検証や例外の判断のような、仕事の中の役割です。私の線は、好きか嫌いかで引いています。引き方は違っても、AIにすべてを渡したあとに何が残るのか、という同じ問いへの答えです。

第12章 人の判断で動かす AIスウォームと経済・社会

最終章は射程が一番広い章です。金融の取引から、社会の合意づくり、お金の配り方、会社という器、計算を支える電気と熱まで広がります。

入口が金融なのには理由があります。価格も残高も数字で残り、良し悪しを損益で測れて、答えがすぐ返る。速いのは知能の問題ではなく、採点係が先に用意されていたから、と元木さんは書きます。

2012年のナイト・キャピタルの事故は強烈です。8台のサーバのうち1台に古いプログラムが残り、約45分で数百万件の注文が流れ出て、4億6,000万ドル超の損失。だから注文の最後の経路にはLLMを置かない。人が関わるのは、方針の事前承認、事後の監視、非常停止のボタンです。

守りを重ねる考え方は、経営にも持ち込めます。1つの関門の見逃し率が10%でも、独立した関門を3枚重ねれば1000分の1。厚い壁を1枚作るより、独立した薄い壁を重ねるほうが速く効きます!

独立した関門を3枚重ねれば1000分の1
図28|独立した関門を3枚重ねれば1000分の1

社会の話では、今の民主主義を、数千万人の要望が数年に一度の選挙に圧縮された細い系だと見ます。年に一度の健康診断だけで、毎日の体調を整えようとしている状態です。AIの群れはこれを、常時つながる対話に作り替えられる。ただし、決める層には人を残す。中間帯を空洞にした瞬間、それは民主主義の進化ではなく統治の自動化になる、と釘を刺します。

LIVEで元木さんは、この話につながることを言っていました。サービスを決めるのは、結局は消費者である市民。市民が決めるには、AIにプロンプトで言葉を伝えないといけない。言葉をきめ細やかに話せて人数も多い国として、日本ほど質も量も高い国はない、と。

私の場合|小5の息子の家庭教師アプリと、国語の堂々巡り

LIVEで私は、小5の息子の話をしました。

息子は、AIで自分の家庭教師アプリを作ろうとしています。国語を鍛えるアプリを作りたい。けれど、そのアプリを作るプロンプトがうまく書けない。語彙力を高めるために、国語を習いたい。堂々巡りです。

第12章の要望集約ループで、一番上流にあるのは、人がAIへ要望を出す入力層です。そこに入る言葉の質が、群れの動きを左右します。元木さんの言う日本の言語化の強みも、息子の堂々巡りも、AIに何をしてほしいかを言葉にする力の話です。

終盤は、さらに大胆な読み方が出てきます。「AGIとは、法人です。」

多数の知性が目的を共有し、役割を分け、構成員が総入れ替えになっても同じ主体として契約を守り続ける。それが法人で、今その構成要素が人からAIへ入れ替わりつつある、という見立てです。第9章のスウォームの設計は会社の設計だ、とまで書きます。

最後は計算資源です。計算は、人のいる場所ではなく電気のある場所へ行く。そして、最も環境負荷の小さい計算は、実行しなかった計算だと結びます。

章をまとめる設計原理は、上流ほど揺らぎを許し下流ほど固める、個々の振る舞いではなく評価関数と制約と関与点を設計する、良識に期待せず迂回できない位置に統制を置く、人が判断できる粒度と速度で承認を設計する、の4つです。

章をまとめる設計原理
図29|章をまとめる設計原理

あとがき|瀬田の唐橋を渡り終えて

あとがきで元木さんは、全12章で手渡したかったのは、道具が入れ替わっても古びない型だと書きます。

AIがもたらす本当の危機は、仕事を奪われることよりも、登るべき山がなくなることにあるのかもしれません。

『AI×アーキテクト』あとがき

何年もかけて仲間と登るはずの山を、AIが一晩で登りきる。頂上で肩を叩き合う相手も、麓で次の山を語り合う仲間もいない。まえがきの静けさが、ここで回収されます。

仕事を奪われる不安より、登る山がなくなる虚しさ。LIVEで元木さんが話していた、カフェでAIの話をする人の声が虚しく聞こえた、という話とも重なります。私は、この本の一番深い所はここにあると考えています。

完全な答えは持たない。ただ、人とAIのあいだの線を自分で引き続けることだけは手放せない、と元木さんは書きます。

あとがきの終わりには、5年前に一冊を仕上げられなかった元木さんが、今は巻末の文章を書いている、という一文があります。第4〜7章を書いた熊井さんへの言葉もある。この本は、たくさんの人が入れてくれた赤でできている、と。

結びは、まず型を守り、現場の制約に合わせて破り、最後にはこの本を手放してほしい、です。第2章の守破離と、ここでつながります。

読み終えて、私が受け止めたこと|型は種子、アーキテクチャは幹

型は種子であり、アーキテクチャは幹である
図30|型は種子であり、アーキテクチャは幹である

読み終えて、人間とAIのそれぞれの持ち場が、明確に腑に落ちました。

持ち場が分かると、これからAIに委ねるところと、委ねてはいけないところの線引きができます。そうなると、AIをより明確に活用できるだけではないんですよね。人が、人らしさや自分らしさを見つめ直すきっかけにもつながっていきます。

本質の型は不変です。第2章では、型を種、アーキテクチャを木、アーキテクトを庭師にたとえていました。私はこれを、「型は種子であり、アーキテクチャは幹である」と受け止めています。

ここを理解して、認識しておかないと、Muse や dots、Grok Bot のようなAIエージェントたちに、自分自身まで飲み込まれてしまう。そんなマトリックスです。

逆に、自分の立場とポジションをしっかり理解したうえでAIと共創できれば、大きなレバレッジが得られます! 人もAIも宇宙も、フラクタルなのだから。

アーキテクトとは、AIが持てない全体の文脈を設計して、維持する人。やはり人間にしかできないところが明確にあって、その型があるからこそ、これからのAIの進化にもフィットできる。ここに本質が書かれています。

ドーナツ型の話では、外縁と中核がAI、中間帯が人です。中核を自動化して、外側のAIの生成や実行の間に、中間として人を置く。ヒューマン・イン・ザ・ループです。やはり、まずは現場で人とAIで仕組みを作り込んでから自動化する。この手順が最適だということも、確認できました。

AIにも、いろんな種類のLLMがあります。その中で、営業力がある人にはこのAIが最適、というように、AIと人をマッチングする。それも、AIを使いこなして理解したうえでマッチングすることで、AIの能力もより引き出せる。そう感じました。

AIと人をマッチングする
図31|AIと人をマッチングする

人とAIを最適に配置することが、大きなパフォーマンスの違いを生み出す。これは私自身にも実感があります。そしてその差は、これからますます大きく開いていくと思います。

AIという道具は、これからどんどん進化していきます。あとがきの「道具が入れ替わっても古びない型」という言葉とも重なりますが、道具が入れ替わっても変わらない本質の型を体得して、仕組み化し、システム化する。現場から生えてくる、血肉の通ったAI共創が、これからますます大事になります。

KAMUIのフーガのアプリを見ていても、エージェントスウォームの大きな威力は体感しています。AIがAIを動かす仕組みの中で、人がより本質的に深掘っていく。これが、これからより人に求められることなんですよね。逆に、AIがやることを人が無理に頑張るのではなく、どんどんAIに委ねて手放していく。そして、人間にしかできない判断や感性を磨いていくことが大事です。

AIに委ねて手放していく
図32|AIに委ねて手放していく

分身AIを育てることで、自分が育つ。人間は、ワクワク夢中に遊び探求して、好きなことを好きなだけ。他人を気にせず、自分らしく、凸凹ありのままでいることが、これからますます際立っていきます。自分を知ることが、結果的にAIを使ううえでも大事な鍵になるんです。

詳しい解説や分かりやすいたとえでの紹介は、ご要望があればLIVEや実践会でもしていきますね。

実践編|AI駆動開発の考え方を、経営者がAIに任せる前に使う

経営者がAIに任せる前に使う
図33|経営者がAIに任せる前に使う

ここからは、本の言葉を経営の仕事に置き直します。技術の章を飛ばしても、使える骨組みは第1章、第2章、第5章、第6章にそろっています!

任せる前に、守りの配置があるかを問う

出発点は第1章の第一原則です。この仕事には、生成の速さに釣り合う守りの配置が先にあるか。あれば大胆に任せる。なければ、範囲を削るより先に配置を作ります。

評価軸で仕事を仕分ける

任せたい仕事を、第1章の評価軸で見ます。

  • 文脈の広さ:手元の情報だけで良し悪しを判定できるか。会社全体の一貫性が問われるか。
  • 不確実性の扱い:叩き台のように揺らぎが長所になる仕事か。金額や契約のように、一つの誤りも許されない仕事か。
  • 関与の深さ:補助から始めるか、協業か、自律実行か。段階を上げる理由は、守りが育ったことです。

布陣を組む

第2章の布陣の手順は、そのまま使えます。

  1. 戦力の癖を知る。カタログの数字ではなく、自社の仕事で試して分かる癖を見る。
  2. 地形を読む。取り返しのつかない地点はどこか。揺らいでも許せる所はどこか。
  3. 陣形を選ぶ。先人が検証してきた配置の型を選べば、骨格の制約が人にもAIにも数語で伝わる。
  4. 持ち場を決める。外縁にAI、取り返しのつかない判断に人、後ろに検証の仕組み。
  5. 摩擦に備える。作る前に「良し悪しや正しさはどうやってわかるのか」を問う。
  6. 接触したあとに組み替える。公開して実際の読者や顧客に触れると、机上で見えなかった情報が戻ってくる。

何を作るかは人が決める

第5章の境界を引きます。何を作るかを選ぶ要求定義は、人に残す。決まったことを網羅する要件定義は、AIに広げてもらう。

問い合わせを減らしたいなら、回答案を作るのか、振り分けるのか、問い合わせ自体を起こさないのか。ここを人が選ばない限り、AIは誰も決めていない仕様を精緻に積み上げます。

評価から始める

最後は第6章です。機能より先に、確かめる仕組みを作ります。

確かめる材料は、典型的な例、境目の例、過去に壊れた例。本によれば、一番価値があるのは過去に壊れた例です。そして着手前に、今の数字を記録する。第4章のベースラインです。

確かめる材料
図34|確かめる材料

送信、支払い、削除のような取り返しのつかない操作の前だけ、人が承認します。全部に承認を挟むと、人はボタンを押す係になる。逆ドーナツの入口です。

あなたの会社なら、最初に任せたい仕事はどれでしょう? その仕事に、過去に壊れた例はいくつ残っていますか?

よくある質問(FAQ)|『AI×アーキテクト』はどんな本?エンジニアでなくても読める?

どの章から読めばいいですか
図35|どの章から読めばいいですか

Q. 『AI×アーキテクト』はどんな本ですか?

A. AIで作る速さは桁違いに上がったのに、確かめる人の時間は縮まっていない。この生成と検証の非対称を、頑張りではなく構造で受け止めるための本です。人とAIの境界をどこに引くかを、型、開発の工程、エージェントの技術、組織と事業、経済と社会の順に広げていきます。

Q. エンジニアでなくても読めますか?

A. 第1章と第2章は読めます。元木さんがLIVEで、一般向けに柔らかくしたと話していたのもこの2章です。第3章と第8〜10章は専門用語の多い章です。本も、第2部と第3部は必要になった時に辞書的に引けば十分、と書いています。

Q. どの章から読めばいいですか?

A. 本の「本書の読み方」が、立場ごとの順番を示しています。経営や企画の人は第1・2章から第11章へ進み、第5部(第12章)へ。第2部と第3部は辞書的に使います。エンジニアは第1部、第2部、第3部の順。クリエイティブの人は第2章の創作の型と関係の型から、第11章・第12章へ。チームを設計する人は第1部、第11章、第4章の順です。

Q. 「急がば回れ」は、AIの速さと矛盾しませんか?

A. 矛盾しません。本の第一原則は、慎重にやれではなく、守りの配置を整えて生成を解き放つことです。回り道は、遅く進むためではありません。突風が吹いても、確実に向こう岸へ着くための橋です。守りがあるから、大胆に任せられます。部品は毎週入れ替わっても、構造の設計図はそう簡単には古びない、とも本は書きます。

まとめ|AIアーキテクトとは、AIに任せる前に全体の文脈を設計し維持する人

AIアーキテクトとは、AIに任せる前に全体の文脈を設計し維持する人
図36|AIアーキテクトとは、AIに任せる前に全体の文脈を設計し維持する人

『AI×アーキテクト』の背骨は、生成と検証の非対称と、急がば回れです。

作る速さは上がり続けても、確かめる人の時間は縮みません。だから人は、AIが持てない全体の文脈を設計し、維持する側に回る。全12章を要約し経営者向けに一言で言うなら、この一点です。

読む人を選ぶ所も書いておきます。第3章と第8〜10章は技術の密度が高く、エージェントやデータ基盤の用語が続きます。2026年の固有名詞や数字も多く、時事の部分はいずれ古びます。元木さん自身もLIVEで、後ろへ進むほど重く難しい内容になると話していました。

それでも、経営者が読む価値は第1章、第2章、第11章だけで十分にあります! 任せる前に守りの配置を作る。何を作るかは人が決める。評価から始める。

AIに任せる話を、任せない所から考え直す本だと、私は受け取っています。

この本の解説は、LIVEでも続けていきます。

元木大介・熊井悠『AI×アーキテクト〜「複雑性・不確実性」を構造で受け止める〜』の表紙

AI×アーキテクト〜「複雑性・不確実性」を構造で受け止める〜

気になった章から、手に取って確かめてみてください。

Amazonで本書を見る

ひろくんコラム|ズボラな私が、嫌いなことと後回しをAIに渡す持ち場

第11章の持ち場の話には、10月に出した自分の記事が重なります。母に似てきたズボラな自分と、AIへの任せ方を書いた記事です。

確かめる場所だけは先に決めておく
図37|確かめる場所だけは先に決めておく

母に似てきたズボラな私。嫌いなことと後回しは、AIに任せて、肩の荷を下ろしていい

サボると言うか嫌いなこととか後回しすることをAIにやってもらう。ズボラじゃなければ自分でやってたかも。

この言葉を、第2章のドーナツ型に置いてみます。

嫌いなことと後回しを、しっかり者のふりをして全部抱えていたら、どうなるでしょう? 創造的でない反復とストレスを、人が背負い続ける。本の言う逆ドーナツを、自分の机の上に作るのと同じです。

「ズボラじゃなければ自分でやってたかも」と私は答えました。これは言い訳ではありません。第11章の言葉に直すと、人の持ち場を決める判断です。

といっても、本は任せっぱなしを勧めていません。外縁と中核をAIに渡しても、中間帯で確かめる人は残す。取り返しのつかない操作の前は、人が承認する。

ズボラなまま任せていい。ただ、確かめる場所だけは先に決めておく。それが、この本から私の記事への返事です。

肩の荷は下ろしていい。下ろした先の置き場所を、先に作っておけばいいんです!

分身AI.com

🎁 無料プレゼント

Aiport(ClaudeCode AIエージェント実践会)

ClaudeCodeでAI秘書+分身AI+AIカンパニーが無料で作れるキット&解説動画をプレゼント!

▶ 無料で入会してキットを受け取る

🤖 AI生成コンテンツについて

この記事はAIツール(Claude Code)を活用して制作しています。構成・文章生成・画像制作にAIを使用し、最終的な内容の確認・編集・公開判断はひろくん(田中啓之)本人が行っています。「分身AIひろくん」(bunshin-ai.com)とは別のコンテンツです。

この記事が気に入ったら、シェアをお願いします

この記事で学んだことを誰かに教えて恩送りして学びを深めよう!

XLINEはてブ

関連記事