- AIの産業構造は6レイヤー。長期の本命は Harness と Applications
モデルは急速にコモディティ化する。「どのモデルを使うか」だけでは競争力は決まらない - 競争力の源は、その会社にしかない「alpha」
データ・業務フロー・判断基準・権限・そして"AIの案をなぜ直したか"の修正履歴。これをソフトに載せたものが「会社OS」 - 会社OSを現場に実装するのがFDE
共通基盤 × 企業固有のalpha × 現場に実装するFDE。現場知を製品資産に変えられるFDEだけがスケールする
CHAPTER 1
チャマスの6レイヤー — AIの産業構造をどう見るか
著名VC チャマス・パリハピティヤの「AI投資ガイド」が面白いです。かなりのポジショントーク込みですが（笑）、AIの産業構造を下から上へ6つのレイヤーに分けて、どこに賭けるかを整理しています。
各レイヤーへの見方を1枚にすると、こうなります（2026年8月時点のガイドより）。
| レイヤー | チャマスの見方 | 位置づけ |
|---|---|---|
| 1. LPS 土地・電力・箱 | 最も明白で、最速でリターンを出しやすい。系統電力＋Behind the Meter。2029年までに約6GWを確保済み | 短期の本命 |
| 2. Silicon 半導体 | もう投資・インキュベートしない。性能要求・製造精度・周辺サプライチェーンが難しすぎる | 見送り |
| 3. Clouds クラウド | 儲かるが難しすぎる。構築も維持も超高コスト・技術的に複雑・強固なKYCが必要・政府責任リスク | リスク歪む |
| 4. Models モデル | 最大の問いは「売上の質」。トークン消費に依存した売上ではないか。ARRが目減りする可能性 | 見極めが核心 |
| 5. Harnesses ハーネス | ここが本命。企業の"独自のコンテキスト"＝alpha を所有させる層。モデル非依存で低スイッチングコスト | 長期の本命 |
| 6. Applications アプリ | Harnessと並ぶ長期勝者候補。既製品とカスタムの境界が溶け、企業ごとのalphaを業務ソフトに埋め込む | 長期の本命 |
CHAPTER 2
モデルはコモディティ化する — だから重要なのは「alpha」
これからAIモデル自体は、急速にコモディティ化していきます。OpenAI、Anthropic、Google、オープンモデル——用途・価格・性能に応じて複数のモデルを切り替えて使うのが当たり前になる。
そうなると、企業の競争力は「どのモデルを使っているか」だけでは決まらなくなります。本当に重要になるのは、その会社にしかない独自の文脈です。
企業固有の「alpha」とは
- どんなデータを持っているか
- どんな業務フローで動いているか
- どの数字を重視しているか
- 誰が何を承認できるか（権限）
- どの条件なら契約し、どの条件なら断るか（判断基準）
- AIが出した案を、なぜ採用し、修正し、却下したか（フィードバック）
これらをチャマスは、企業固有のalphaと呼んでいます。モデルを乗り換えるコストはどんどん下がる。一方で、この会社固有のalphaが蓄積されるほど、その価値はどんどん上がっていきます。
CHAPTER 3
Harnessと「会社OS」 — データをつないだだけでは足りない
Harnessとは、AIにどの情報を見せ・どのツールを使わせ・どんなルールや評価基準のもとで仕事をさせるかを設計する層です。ただ、企業で本当に価値を生むには、その上に企業固有のalphaを載せなければならない。
そこで、企業固有のデータ・業務フロー・判断基準・権限・AIによる実行までを統合したものを、私は会社OSと呼んでいます。
・社内文書を検索できる
・議事録を要約できる
・チャットで質問できる
——これは、まだ入り口です。
CHAPTER 4
会社OSは「ループ」で閉じる — 最も価値の高いデータは修正履歴
会社OSでは、社長の意図が意思決定になり、具体的なActionになり、最終的な事業成果につながる。そして、その結果が次の意思決定に戻っていく。このループまで閉じて、初めて会社固有の経営モデルが蓄積されます。
特に価値があるのは「差分」
完成した文書だけではありません。AIが最初に出した案と、人間が最終的に修正した案の差分です。
- なぜ人間が直したのか
- どの判断が成功したのか
- どの前提が間違っていたのか
- なぜ採用し、なぜ却下したのか
※プログラムの「AIの第二の脳」の考え方と地続き → AIの記憶と第二の脳のつくり方
このループを「事業管理」の言葉で描いた図は → CHAPTER 8｜会社OSの中身を図で見る
CHAPTER 5
この会社OSを実装するのがFDE
そして、この会社OSを企業の中に実装するのがFDE（Forward Deployed Engineer）です。FDEは、単なるAIコンサルでも、受託開発でもありません。
現場に入り込み、経営者や社員の頭の中にある暗黙知を、ソフトウェアに落としていく仕事です。
| 頭の中にある暗黙知 | ソフトに落とすと |
|---|---|
| 持っている情報 | データ構造 |
| 仕事の進め方 | 業務フロー |
| 何を良しとするか | 判断ルール・評価基準 |
| 誰が何を決めるか | 権限設計 |
| 案をどう直すか | AIへのフィードバック |
CHAPTER 6
「FDEはスケールしないのでは？」への答え
ここで、必ず出てくる反論があります。
これは、半分正しいです。毎回ゼロから、人月を使って個別開発するなら、普通の受託開発で終わります。
でも、個社への実装で得た——データ構造・コネクタ・業務フロー・権限設計・評価基準・AIの実行パターン——を共通基盤へ戻していけば、案件が増えるほど個別開発の比率は下がり、共通ソフトウェアの比率が上がっていきます。
現場で得た知識を、次の導入を速くする製品資産に変えられるFDEだけがスケールする。ここが、従来のコンサルや受託開発との大きな違いです。
CHAPTER 7
SaaSは「会社ごとに変わるソフト」へ
チャマスは、既製品のSaaSの多くが、企業ごとのカスタムソフトウェアに置き換わると考えています。方向性には同意します。ただ、すべてを毎回ゼロから個別開発する世界になるとは思っていません。共通する部分は徹底的に共通化し、その上に会社ごとのデータ・ルール・権限・評価基準・ワークフローを実装する。
| これまでのSaaS | これからの会社OS | |
|---|---|---|
| 合わせる向き | 企業がソフトに業務を合わせる | ソフトが企業の仕事の仕方に合わせて変わる |
| モデル乗り換え | — | コストはどんどん下がる |
| 会社固有の文脈 | ソフトの外（人の頭の中） | ソフトに蓄積され、価値はどんどん上がる |
FDEは、一時的なAI導入支援ではありません。会社固有の経営や業務そのものを、AI時代のソフトウェアに変えていく仕事です。
CHAPTER 8
会社OSの中身を図で見る — 事業管理を「botが参照できる形」で持つ
CHAPTER 3〜4で、「データをAIにつないだだけでは会社OSにならない」「意図→意思決定→Action→成果のループを閉じて、初めて蓄積される」と書きました。では、具体的に何を、どんな形で持たせればいいのか。X（旧Twitter）で公開されていた図解3枚が、その中身を事業管理の言葉で描いていたので、出典つきでそのまま載せます。
図2＝どう流すか（目標・仮説・予測・行動・実績・更新ルールを、参照→実行→観測でつなぐ）
図3＝誰が何をするか（人が決める範囲と、botが回す範囲の線引き）
図1｜各事業の6つの管理対象を、共通の文脈で接続する
図1の文字おこし（画像の文字が小さいとき用）
各事業の6つの管理対象を、共通の文脈で接続する
商品・仮説・数値・組織・施策・更新条件を、botが参照できる事業管理として持たせたい。
| 箱 | 書いてあること |
|---|---|
| 【上段】設計・前提・計画 | |
| 商品設計 | 誰の課題を、何で、いくらで解くか 対象顧客／提供内容／価格・条件 決定した内容と、妥当性の検証を分ける |
| 仮説マップ | 顧客 → 商品 → 集客 → 成約 継続 → LTV → 利益のつながり 言語の仮説・数値前提・根拠を結ぶ |
| 数値計画 | 目標／予測／実績を別々に参照 （表計算シートの画像つき） |
| 【中央】 | |
| bot | botが、事業の同じ文脈を参照して判断する どの仮説に、どの施策が効き、どの指標・根拠で評価するかをたどる |
| 【下段】実行体制・施策・変更条件 | |
| 組織・提供体制 | 必要な役割・人員・能力・提供量 施策に必要な能力と余力を確認 いつ・どれだけ必要かを計画へ返す |
| 施策・タスク | 指標・仮説 → 施策 → 担当・期限 誰が・いつ・何を実行するか 成果の観測項目を持ち、完了後も評価する |
| 更新ルール | 何を観測し、どの条件で変えるか 継続・変更・停止と権限を持つ 確認周期／臨時見直し／停止・撤退 根拠と過去の計画を残す |
矢印（つながり）
商品設計 →「前提」→ 仮説マップ →「数値化」→ 数値計画
商品設計・仮説マップ・数値計画 → bot（中央）
bot →「役割・余力」→ 組織・提供体制
bot →「実行指示」→ 施策・タスク
bot →「判断条件」→ 更新ルール
施策・タスク →「必要資源」→ 組織・提供体制
更新ルール ┄┄（点線）→ 組織・提供体制 側へ「観測した結果と根拠で、設計・体制・施策を選び直す」
読みどころ：6つを別々の資料に散らさず、botが「同じ文脈」としてたどれるようにつないでいる点です。商品設計の「決定した内容と、妥当性の検証を分ける」、数値計画の「目標／予測／実績を別々に参照」——"決めたこと"と"確かめたこと"を混ぜないのが、3枚を通した作法です。
図2｜6つの管理要素を、参照・実行・観測の流れでつなぐ
図2の文字おこし（画像の文字が小さいとき用）
6つの管理要素を、参照・実行・観測の流れでつなぐ
事業管理＝目標＋仮説＋予測＋行動＋実績＋更新ルール。目標・予測・実績は分けて持つ。
| 箱 | 書いてあること |
|---|---|
| 【上段】目的・前提・権限を管理する層 | |
| 目標 | 実現したい状態 目的・期限・評価指標 |
| 仮説 | 顧客・価値・価格・利益の因果 人が仮説を定め、根拠と結ぶ |
| 更新ルール | 周期／臨時の見直し／停止条件 変更権限／根拠／計画の履歴 |
| 【中段】観測値と前提を照合する処理層 | |
| 予測 → 差分比較 → 試算・行動案 | 仮説・計画・証拠から見込みを出し、目標との差を見つける 前提：価格・成約率・継続率・LTV・費用など |
| 【下段】 | |
| 行動 | 結果を変える施策・タスク 担当・期限・観測指標を紐づける |
| 現実の事業 | 広告を出す ≠ 顧客が増える 商品改善 ≠ 継続率が上がる タスク完了と事業の前進は別 間にある仮説を証拠で検証する |
| 実績 | 実際に観測した結果 出典・取得時点・未取得を保持 |
矢印（つながり）
目標 ⇄ 処理層「比較基準」
処理層 ┄┄（点線）目標「予測の修正だけで目標を自動的に下げない」
仮説 →「前提と証拠」→ 処理層
更新ルール →「変更可能範囲」→ 処理層
処理層 →「施策を選ぶ」→ 行動 →「実行」→ 現実の事業
現実の事業 →「利用・成約・継続・費用を観測」→ 実績 →「結果を返す」→ 処理層
読みどころは2つです。①「予測の修正だけで目標を自動的に下げない」——見込みが悪くなったとき、AIが目標の側を下げて辻褄を合わせることを禁じています。②「タスク完了と事業の前進は別」——広告を出した（タスク完了）からといって、顧客が増えたとは限らない。間にある仮説を、実績という証拠で確かめる。
図3｜目標達成へ、botが実データを見に行く事業運営の構想
図3の文字おこし（画像の文字が小さいとき用）
目標達成へ、botが実データを見に行く事業運営の構想
数値計画・外部の観測・AIの処理・人の判断をつなぎ、現実との差から計画と行動を選び直す。
| 箱 | 書いてあること |
|---|---|
| 人が、目的・委任範囲・仮説を定める | 目標と権限の境界を設定。重要な変更は人へ戻す。 |
| 【中央の枠】委任範囲内で回すAIの処理 | |
| botが観測・比較・試算 | 計画と実データを照合 差分・不足する根拠を発見 仮説・数値前提・施策の候補を比べる 予測を変えても目標を自動的に下げない |
| 施策・タスクの実行 | 誰が・いつ・どの仮説に働きかけるか 観測 → 試算 → 提案 → 行動 → 更新 |
| 【左】 | |
| 数値計画 | 目標／予測／実績 （表計算シートの画像つき） 正式計画・見込み・観測結果を分けて持つ 未取得をゼロ扱いせず、前提と出典を残す |
| 計画・仮説・行動の更新 | 承認された変更を適用 根拠と過去の計画も保存する |
| 【右】 | |
| 実データの取得先 | 会計・決済／広告／顧客データ 売上・費用・成約・継続 顧客の発言・利用状況 取得時点・出典・観測範囲を確認 取得できない値も区別して扱う |
| 重要な変更は人が判断 | 影響を確認し、承認・差戻し 停止・撤退は判断条件に従う |
矢印（つながり）
人が定める →「委任と仮説」→ botが観測・比較・試算
数値計画 →「参照」→ bot
bot →「取得に行く」→ 実データの取得先 →「観測結果」→ bot
bot →「行動案へ」→ 施策・タスクの実行
実データの取得先 ┄┄（点線）→ 施策・タスクの実行「実行後の成果を再観測」
施策・タスクの実行 →「範囲内は更新」→ 計画・仮説・行動の更新 → 数値計画
施策・タスクの実行 →「提案・確認」→ 重要な変更は人が判断 →「承認された変更を、計画と次の行動へ」→ 計画・仮説・行動の更新
読みどころ：botに任せるのは「委任範囲内」の観測・比較・試算と、範囲内の更新まで。重要な変更は人へ戻し、承認されたものだけが計画と次の行動に入ります。実データの側にも「未取得をゼロ扱いしない」「取得できない値も区別して扱う」と、"分からない"を"ゼロ"にすり替えない作法が書き込まれています。
・「根拠と過去の計画も保存する」＝ CHAPTER 4 の修正履歴（なぜ変えたか）を残す仕組み
・「目標と権限の境界を設定」「重要な変更は人が判断」＝ CHAPTER 2 の alpha のうち権限と判断基準
出典：X投稿（2026-11-05）https://x.com/yoshio_nocode/status/2118311427832500601
※図1〜3はすべて上記投稿の画像を転載（文字おこし・読みどころは本教材で追加）