AI-Native Redesign: 原理は変えず、仕組みを壊す

みなさまこんにちは！エアークローゼットでCTOをしている辻です。

「AIで全部変わる」という風潮がありますが、私が社内でAI活用基盤(cortex)を組み立て、そして運用してきた実感はむしろ逆です。原理は何も変わらない。ただ仕組みだけが変わる。この記事では、私が何を原理ととらえ、何を壊すべきと考えてきたのか、その思想について紹介します。

これまでcode-graph、product-graph、db-graph、biz-graph、AI-Observability、auto-review harness、Self-Healingと、個別の実装について書いてきました。今回はそれらの話ではなく、全部の背後にある設計原理そのもの。個別実装から一段抽象度を上げた、思想寄りの話です。

その原理とは、一言で言えば「正確な情報に、適切にアクセスできるようにするには？」という設計問題です。これは実は人類が長らく抱えてきた根本的な問いで、図書館から検索エンジンまで、時代や対象等によって手段は違えど本質は同じ問いを解こうとしてきました。過去に何度も起きた革命的な技術革新でさえ、手段を刷新しただけで根本にある問いは変えていません。

そして今、AIという新たなパラダイムシフトに対して、私としては(おそらく一般的な感覚でも)それがインターネットに匹敵する、もしくはそれを超えるレベルの技術革新だととらえています。そして過去がそうであったように、この「正確な情報に、適切にアクセスできるようにするには？」という問いの実現手段は根本から再設計されることが必然です。これがこの記事のテーマ、AI-Native Redesign(AI前提の全体再設計)です。個別の「AIツール導入」でも「LLMでRAGする」でもなく、本質的に今後も変わらないこの原理を、AI前提で全体設計し直すという視点。

不変の原理

3つのノードに分けて考える

この原理を、作成 / 維持 / 消費の3つのノードに分けて整理してみます。作成する人(あるいは仕組み)が居て、維持する人が居て、消費する人が居る。

たとえば図書館なら、作成=目録・分類体系を作る、維持=新刊を追加し目録と配架を更新する、消費=利用者が本を借りる。法律・判例集と弁護士なら、作成=裁判所が判決を残す、維持=判例集に新判例が追加される、消費=弁護士が該当ケースを引いてクライアントに提供する。エンジニアリング組織のドキュメントなら、作成=機能仕様やREADMEを書く、維持=コード変更に合わせて更新する、消費=他のエンジニアが実装時に参照する。どの例でも、3つのノードそれぞれに担当があり、全部が回って初めて成立します。

この3者が信頼とインセンティブの連鎖で回っている限り、仕組みは自己維持する。ひとつでも欠けると、負のスパイラルに陥って全体の品質が徐々に下がっていきます。具体的なメカニズムはこの章の後半で扱います。

「情報」が何を指すかは対象によって違います。書物の知識、法律の判例、企業の業務ドキュメント、機械の実行時の挙動、顧客の傾向、意思決定の背景。共通するのは、それが誰か1人の頭の中にしかない限り、規模が上がった瞬間に機能不全を起こすということ。参照可能な形で保存されて適切にアクセスできるようになって初めて、規模のある活動が成立します。

変わってきたもの、変わっていないもの

変わってきたのは実装手段です。古代の粘土板や巻物、口伝の伝承、写本、辞書と索引、印刷術、法律書と弁護士、図書分類、そして直近の数十年ではwikiや紙のドキュメント、APMや構造化ログ、検索可能なナレッジベース、分散トレーシング、大規模検索エンジン、BIダッシュボード、RAG。時代ごとに、その時々の技術で3ノードのバランスを最適化しようとしてきました。

wikiが90年代に最適だったのは、人が書く・人が更新する・人が探すが唯一の実装手段だったから。APMが2000年代に出てきたのは、機械が生成するテレメトリを保管できるストレージコストが現実的になったから。各世代が独自の対象と独自の技術で答えを出してきました。

でも根本の問いは変わっていない。すべての時代のあらゆる分野が、「正確な情報に適切にアクセスできるようにする」という同じ問題を、その時代の道具で解こうとしてきたにすぎません。3ノードのバランスも、ある意味では意識的に設計しようとしてきたはずです。ただし人が関わる以上、書くことをサボり、更新を忘れ、間違え、やがて維持できなくなって破綻していく。もちろん、破綻せずに機能し続けてきた仕組みもあります(図書館制度、法体系、確立された学問分野など)。ただし多くの場合、人手の限界が制約となって、負のスパイラルの側に落ちてきました。

AIが画期的なのは、ほぼ人手をかけずに作成・維持を回せる領域を大幅に広げた点にあります。作成・維持の自動化そのものは、決定論的なシステムによって既に広く実現されていて、我々が普段意識しないほど当たり前になっている。エンジニアリング系のインフラ(APM、CI/CD、ログ収集、スキーマ検証)に限りません。たとえばメディアサービスも同じ構造で回っています。記事の作成・更新・削除がシステム化され、配信を通じてアプリ・Webサイト・紙面で読者に届く。銀行の取引システム、ECの商品カタログ、地図アプリの経路データ、ソーシャルメディアのタイムライン。挙げればきりがないほど、決定論的自動化は日常のあらゆる場所にある。ただし、決定論では手が届かない領域が残っていました。人の意思決定、設計文脈の言語化、コード変更に追従したドキュメント更新、annotationの付与など、定性的な判断や文脈理解を要する部分です。AIはこの領域までカバーできるようにした。加えてAI自身が消費側にも回れる(APMでいえば、ダッシュボードを見て改善サイクルを回す部分の自動化まで届く)。人手が構造的に減ることで、初めて多くの分野で正のスパイラルが回せるようになる。ただし、この拡張された可能性を自組織のループにどう組み立てるかは、依然として人の設計判断です。ここが本記事のテーマ「AI-Native Redesign」の中心です。

各ノードを詳しく見る

3つのノードそれぞれを、もう少し丁寧に見ていきます。

作成(creation) 情報を参照可能な形で保存する行為。コードの構造をドキュメントとして書き起こす、実行時の挙動をログやトレースとして吐かせる計装を仕込む、意思決定の背景をdesign docとして残す、顧客の傾向をKPI定義として言語化する。何かを後からアクセスできる形にして残す作業全般がここに入ります。

維持(maintenance) 一度保存したものを、源泉が変化しても乖離しないよう更新し続ける行為。コードが変わったらドキュメントも、サービス構造が変わったらメトリクス定義も、顧客傾向が変わったらKPIも、決定が上書きされたら記録も。「作成」が一度きりの作業なら、「維持」は継続的な作業です。

消費(consumption) 保存されたものに実際にアクセスして意思決定や行動に使う行為。人間が読む、機械が問い合わせる、アラートが発火する、AIエージェントが文脈として引く。全部ここに含まれます。

この3つは、単に順序的なフェーズ(作成 → 維持 → 消費)ではありません。互いに信頼とインセンティブの連鎖で結ばれた1つの仕組みであって、個別に評価できない構造をしています。

3ノードの負のスパイラル — なぜ多くの現場で崩壊するのか

3ノードの相互依存性を具体的に分解するとこうなります。

• 消費されなければ作成の動機がなくなる。誰も読まないドキュメントを書き続ける人はいない。誰も見ないダッシュボードを作り込むエンジニアはいない
• 維持されなければ消費に耐えなくなる。半年前のドキュメントは「たぶん古い」と判断されて読まれない、メトリクス定義が変わったのに気付かれないダッシュボードは誤った意思決定を生む
• 作成されなければそもそも維持する対象がない。参照可能な形で保存されていない情報は、それが変化しても検知しようがない

3者が互いに「自分がやる価値がある」と信じている限りループは回ります。でも1つでも高コストになると、その1つの担当者だけでなく他2つの担当者もインセンティブを失う。「どうせ誰も読まないし、すぐ腐る」「更新しても誰も気にしない」「探しても古いか不正確」という3つの「やらない理由」が互いを補強し合って、負のスパイラルが加速する。

これが多くの現場でドキュメント文化が定着せず、監視システムが陳腐化し、ナレッジベースが空洞化してきた根本理由です。ツール自体に責任があるわけではない。3ノードのうち1つでも高コストなら、他2つがそれを補うインセンティブを失い、仕組み全体が沈黙のうちに崩壊する構造だから、個別ノード改善では抜け出せない。

「うちの会社のConfluenceには10万ページあるけど、誰も読まないし、誰も更新してない」という状態を経験した人は多いと思います。これはConfluenceというツールの問題ではなく、3ノードのうち少なくとも2つ(作成と維持)が高コストなまま、消費側だけを検索機能で改善しようとした結果として、ループが閉じなかった、という構造的な問題です。

この記事の残りで何をやるか

ここから先の議論はすべて、この原理(適切にアクセスできるようにして、3ノードのループで回す)を軸に展開します。

• 第2章では、身の回りにある具体例(業務ドキュメント、監視、業務データ、スキーマ管理、セキュリティなど)を並列に並べて、それぞれが独立に3ノード問題を抱えてきたことを示す
• 第3章では、AIがなぜ決定的な転換なのかを、「決定論では届かなかった領域を初めて自動化の射程に入れる」という観点から論じる
• 第4章では、cortexでのAIネイティブ実装(code-graph / db-graph / biz-graph / product-graph / Observability)を並列で解説する
• 第5章では、「AIツール導入」と「AI-Native Redesign」の違い、AI以前の設計を残したままAIを足すと失敗する理由を掘る
• 第6章では、自己維持するループを多層で持つ組織と持たない組織で、進化速度の差が非線形に広がっていく風景を描く

各章は独立して読めますが、順に読むと「不変の原理 → 身近な適用例 → AIの特殊性 → 実例 → 再設計論 → 未来」という1本の論理連鎖として通る構造にしています。

決定論では手が届かない領域

決定論的自動化は既にあらゆる場所に浸透していると述べました。でも決定論では手が届かない領域が残っている、とも述べました。この章では、その残された領域を具体的に分解します。

分野ごとに3ノードを分けて見ていくと、大きく2つのタイプに分かれます。

タイプ1: 特定ノードに人手依存が残っている分野

一部のノードは決定論で自動化できているのに、別のノードで人手依存が残る分野。並べてみると:

人手依存が残るのは、いずれも定性判断や文脈理解が必要な部分です。特に多くの分野で「消費側」にボトルネックが集中する(「情報はあるのに使われない」が典型症状)。人間が大量のダッシュボードやログを同時に解釈するには認知的な限界があり、そこが構造的なボトルネックになってきました。業務ドキュメントだけは3ノード全部が人手で、最も課題が顕著な特殊ケースです。

タイプ2: 作るコストが消費メリットに見合わなかった領域

タイプ1とは別に、もっと根本的なカテゴリがあります。「そもそも試みられなかった」領域です。個別データやコードは存在するけれど、その間の「関係を構造化する仕組み」を作ろうにも、コストとメリットが釣り合わなかった分野。これはたとえば、コードやテーブル間の関係のように既に存在するのに人には見えないケースや、施策とKPIの因果関係のようにそもそも関係が定義されていないケース、といった領域です(後述するタイプ2aとタイプ2bにあたります)。

興味深いのは、こうした構造化の作成そのもの(静的解析による抽出、SQLによる集計、グラフ構築のパイプライン)は、多くの場合決定論的なロジックで実現できるという点です。「作れなかった」のではなく「作る割に合わなかった」というのが正確な理由でした。

なぜ手をつけられなかったかを分解すると、コスト側とメリット側の両方に問題があった、いわばダブルパンチ状態でした:

• コスト側: たとえ決定論的ロジックで作れるとしても、構造化を実現するシステム(静的解析、抽出パイプライン、グラフ基盤)を最初から立ち上げるには相当な開発労力が必要
• メリット側: 仮に作れても、人が有効に消費できない。グラフを人が辿るのは現実的でないし、意味的な検索の仕組みも無い
• コストが大きく、メリットが薄い組み合わせでは、誰も割に合わないと判断する
• 結果として「あったほうが良かった」ものが、実際には存在しなかった

このカテゴリは更に2つに分かれます。

タイプ2a: 既存関係の可視化(解析の問題)

関係はコードやデータ上に既に存在するのに、それが人には見えない/たどれない領域。たとえば:

• コードベース全体を横断した境界の接続関係(どのAPIが別リポジトリからも呼ばれているか、等)
• テーブル間の意味的関係(どのテーブル群が同じ業務エンティティを表しているか、等)
• 分散システムのログ相関(別サービスのログ間の因果関係)

これらは「情報自体は既にある、でも人には解析できない」という失敗モードです。

タイプ2b: 新規関係の設計(設計の問題)

関係がどこにも存在せず、人が概念モデルとして設計してから抽出しなければならない領域。たとえば:

• 施策とKPIの因果関係(どのキャンペーンがどの数字を動かしたか)
• 意思決定と結果の対応関係(design docの判断が実装後にどう機能したか)
• 顧客セグメントと行動パターンの構造化

これらは「情報が存在すらしない、設計してから抽出しなければならない」という更に深い失敗モードです。個人がExcelや頭の中で管理している関係が、組織規模には対応できない典型例。

以前書いたbiz-graphの記事(施策の効果検証をGraph RAG + MCPで探索可能にした話)では、この2つの違いをこう言語化しました:

DB Graphは「既にある関係を発見可能にした」。Biz Graphは「存在しない関係を設計して作り出した」。前者は解析の問題、後者は設計の問題。

タイプ1とタイプ2の違い

同じ「決定論では手が届かない領域」でも、性質が異なります。

• タイプ1: 「ここが人手だから遅い / 停滞する」(既存ワークフローのボトルネック)
• タイプ2: 「そもそも存在しなかった」(未探索領域の開拓)

タイプ2の方が根本的に大きな変化を生む可能性があります。「ボトルネックを改善する」のは既存ワークフローを速くする効果ですが、「未探索領域を開拓する」のは今まで不可能だった意思決定や洞察を可能にする効果だから。

共通するパターン

タイプ1もタイプ2も、共通するのは決定論(ルールベース)では書けない領域が残っていたことです。

• タイプ1に残っていた部分: 「ダッシュボードの異常を何と判断するか」「マイグレーションをいつどう実施するか」「読者向けに何を書くか」
• タイプ2に残っていた部分: 「どのコードが同じ境界か」「どの施策がどのKPIに効いたか」「Week × MetricDomainのような概念スキーマをどう置くか」

これらすべてに共通するのは、定性的・文脈的な判断や意味的な接続が必要という点。決定論では書けないから、これまで残されてきた。

これが次に扱う「AIが画期的な理由」の直接の前提になります。AIは:

• タイプ1の残された定性判断ノードをカバーする
• タイプ2のコスト側とメリット側の両方でパラダイムシフトを起こす(決定論的な抽出システムの開発ハードルを下げ、かつAI自身がその成果物を意味的に消費できるようにする)

「決定論では手が届かなかった領域」だけでなく、「決定論で作れたのに割に合わなかった領域」まで、初めて自動化の射程に入った。それがAIの新規性です。

AIが決定的な転換である理由

決定論では手が届かない領域が2種類あることを先に見ました。タイプ1の残された定性判断ノードと、タイプ2のコスト・メリットが釣り合わなかった構造化領域。この章では、AIがなぜその両方を初めて自動化の射程に入れられるのかを掘ります。

AIの本質的に新しい部分

AI以前の自動化技術は、すべて決定論的ロジックを書ける領域に閉じていました。ルールを列挙して、条件分岐を作って、パターンをマッチさせる。この技術は非常に強力で、先に述べたように、すでに社会のあらゆる場所に浸透しています。

しかし前章が別角度から辿り着いたのと同じ「決定論では書けない領域」——定性判断・文脈理解・意味的な接続——がずっと残ってきました。人間が「なんとなく理解できる」判断を、コードで表現しようとすると爆発的に条件が増えて破綻する。タイプ1の残された人手ノードも、タイプ2の作られなかった構造化システムも、どちらも「ルールベースで書き下せないこと」が共通の根っこにありました。

AIが初めてもたらしたのは、この領域全体を機械が処理できるようにしたことです。LLMはコードで表現できない判断を、統計的なパターンとして扱える。これは決定論の延長ではなく、決定論と直交する新しい能力です。

3方向のシフト

AIのこの新しい能力は、3つの異なる方向で仕組みを変えます。これらは前章のタイプ1と2の分類に対応していて、方向1がタイプ1、方向2と3がタイプ2の課題を解く形になります。

方向1: タイプ1の残された定性判断ノードを自動化する

タイプ1で見た「特定ノードに人手依存が残っている分野」で、その残されたノードをAIがカバーできるようになる。ダッシュボード解析、脅威判断、ドキュメント更新、KPI解釈といった作業を、AIが人に代わって行う。

方向2: 構造化システムを作るコストを下げる

タイプ2で見た「決定論で作れるが開発労力が大きい」問題。AIは開発の各段階(仕様設計、コード生成、テスト、デバッグ)で開発者を補助することで、こうしたシステムの立ち上げハードルを大幅に下げる。以前なら数ヶ月かかった構造化パイプラインが、数日で組み上がることも珍しくない。実例として、cortexのbiz-graph(施策×KPIの因果関係を扱うMCPサーバー)の初期版は、実装からPulumiによるデプロイまで丸1日で立ち上がっています。

方向3: 構造化されたデータを意味的に消費する

タイプ2の「作っても消費できない」問題を解く。人が手作業では辿れなかったグラフを、AIが意味的な検索と自然言語での問い合わせで踏破する。「先月のマーケティング施策で、新規獲得に最も貢献したのは?」といった問いに、グラフ探索と意味的な検索を組み合わせて答える。

決定論優先の原則

大事な設計原則があります。決定論で書けることは、決定論で書くべき。狙いは、AIに推論を任せる範囲をなるべく狭めること、つまりハルシネーションを閉じ込めることです。決定論で書ける部分までAIに任せてしまうと、ハルシネーションが発生する余地が無駄に広がります。過去の記事で繰り返し使ってきた「ハルシネーションを閉じ込める」設計の実体は、この分担の判断そのものです。

決定論に寄せることで、副次的に他のメリットも得られます:

• 冪等性を保てる: 同じ入力に対して毎回同じ結果が得られる。テスト・監査・再現性の観点で決定的に重要
• コストが桁違いに安い: AIの推論呼び出しはトークン単位で課金されます。決定論的ロジックは実行コストが1桁以上安いことがほとんど

AIをどこに使うかは意思決定です。「AIならなんでもできる」わけではなく、決定論で書ける部分は決定論で書いて、決定論では書けない残りの部分だけをAIに任せる。この分担設計がAI-Native Redesignの核心にあります。

具体的な組み合わせ方の例:

• 静的解析・SQL・パイプライン → 決定論で作る(タイプ2の作成側)
• そこで得られた構造化データを → AIが意味的に消費する(タイプ2の消費側)
• 定性判断が必要な残りの部分は → AIがカバーする(タイプ1)

なぜ「AI前提の設計」が必要なのか

過去の自動化ツール(APM、CI/CD、監視、BI)を導入するときは、既存の運用に「乗せる」形で入れることが多かった。ツールが独立していて、既存のワークフローを壊さないから、追加で入れれば済んだ。

AIは違います。「既存のシステムにAIツールを追加」する形では、前に見た問題は解けません。理由は、AIがもたらす価値が「単独のツール機能」ではなく「3ノード全体のバランス変化」に依存しているからです。

• タイプ1の残されたノードだけをAIで置き換えても、消費側のパイプラインが対応していないと使われない
• タイプ2の構造化を新規に立ち上げても、消費側のワークフローが人手判断ベースのままだと成果物が活かされない
• 定性判断をAIに委ねる部分と、決定論に残す部分の境界を再設計しないと、責任範囲が曖昧になる

だから「AIツールを追加」ではなく「AI前提で全体を再設計」する必要がある。これがAI-Native Redesignの核心で、後で詳しく掘り下げます。

cortexでの実装例

この章では、cortexで運用している具体的な仕組みを並列で見て、これまで述べた原則が個別実装にどう落ちているかを示します。個別実装の詳細はそれぞれ独立記事があるのでリンクを貼ります。ここでは「どこに決定論を置き、どこにAIを配置し、どう分担を判断したか」に焦点を絞ります。

code-graph

code-graphは46リポジトリ横断のコード接続関係(API境界、DB境界、Event境界)を1つのナレッジグラフに可視化する仕組み(タイプ2a: 既存関係の可視化)です。

• 作成: 決定論(tree-sitterによる静的解析)。関数・クラス・importの呼び出し関係を書かれた通りに抽出する
• 維持: コード変更をトリガーに静的解析が再実行される(維持も決定論)
• 消費: AIがMCP経由で意味的検索とグラフ探索を組み合わせて消費する
• ハルシネーション閉じ込めの実装: boundary node(API endpoint、DB table、Event topic)を明示的に静的解析でノード化して、AIの推論範囲を「boundaryで止まる」に絞る仕掛け

db-graph

db-graphはテーブル間の関係とビジネス文脈を扱う仕組み(タイプ2a)です。ORM上のJOIN関係と、業務エンティティレベルの意味的関係の両方をグラフ化します。

• 作成(構造部分): 決定論(ORM定義の静的解析、スキーマ抽出) + 人間レビューで担保
• 作成(ビジネス文脈部分): AIが生成 + 人間レビューで担保
• 維持: ORMやスキーマの変更検知は決定論、ビジネス文脈のdriftは人間レビューで捕まえる
• 消費: AIが自然言語で「どのテーブルが顧客購買サイクルに関わるか」を問い合わせる。グラフ探索と意味的検索を組み合わせる
• ハルシネーション閉じ込めの実装: 構造は決定論。ビジネス文脈はAI生成だが、人間レビューを最終ゲートに置く。cortex-product-graphがAIレビューで回るのに対しdb-graphを人間レビューにしているのは、DBの構造やビジネス文脈が間違うと組織の意思決定に直接影響するため、コードの誤りに比べてリスクが大きいから。「AIで十分な精度が出るならAIに任せる」だけでなく、間違ったときのリスクの大きさに応じて人間レビューのコストを払う判断

biz-graph

biz-graphは施策とKPI間の因果関係を扱う仕組み(タイプ2b: 新規関係の設計)です。DB Graphと違って、施策とKPIの間には「JOINする対象」が最初からありません。関係を人が設計する必要があります。

• 作成: AI(スライドからの構造化抽出) + 決定論(KPIデータ抽出、embeddingsによる類似edge計算) + 人のスキーマ設計(Week、MetricDomainのような概念アンカーを人が定義)
• 維持: 新しい施策スライドやKPI値の更新を継続的に取り込んでgraphを最新に保つ(スライド解析はAI、値パイプラインは決定論)
• 消費: AIエージェントが「先月のSNSキャンペーンと今週の新規獲得数の因果は?」に対して、Initiative → Week → 共起KPIをグラフ探索する
• ハルシネーション閉じ込めの実装: 人間が定義したスキーマ(Week、MetricDomainといった概念アンカー)を決定論的な外枠として与え、その枠内でしかAIが推論できないように制御する。KPIデータ抽出・類似edge計算・グラフ構築は決定論。AIは消費側と、スライドからの構造化抽出時の判断部分に限定される

cortex-product-graph

cortex-product-graphは、cortex自身のコード + DBスキーマ + docs + Pulumi IaCを統合したcortexのメインナレッジグラフです。cortexの開発現場ではAIが積極的に使われていて、そこでAI-Native Redesignの原則がどう機能しているかを示すいい例になっています。

• 作成(構造部分): 決定論(ts-morphでコードとPulumi IaCから@graph-* JSDocを抽出、ドキュメントとdb-graphを統合)
• 作成(コード + annotation): developer + AI-assist(Claude Code / Codexがコードを書きながらannotationも同時に生成)
• 維持: cortexのAIレビューがPR単位でコードのロジック、ドキュメントの整合性、annotationのdriftを全部チェックしてREQUEST_CHANGES
• 消費: AIがMCP経由で意味的検索と構造的検索を組み合わせて消費
• ハルシネーション閉じ込めの実装: PRに対してcortexのAIレビューがコード + annotation + docsをまとめてreviewする。人がreviewせずにmergeされるPRでも、AIが必ずreview layerとして機能する。特にコード本体と@graph-* annotationがJSDocとして構造的に近接している(コードと意図をSSoTとして同一ファイル内に配置する形)ため、AIがコードの変更と意図のズレを瞬時に検知でき、AIレビューが高精度を保ちやすい。これは「AIが読みやすい形にコードを整える」というAI-Readability(コードを人間だけでなくAIエージェントにとっても構造的に読み解ける形にする設計思想)の判断でもある

Observability + Self-Healing

AI-Observabilityは監視の4軸(Application / Infrastructure / CI / LLM)を扱う仕組みで、そこからSelf-Healingにつながる循環構造こそがAI-Native Redesignの真骨頂です(タイプ1: 消費側のボトルネック解消)。

• 作成 + 維持: 決定論(OpenTelemetry、metrics、logs、traces、決定論的アラート)
• 消費(検知): 決定論的なアラート閾値でインシデント発火
• 消費(判断・対応): AIがログやtraceの文脈(実装ではGrafana MCP経由で引く)と、cortex-product-graphで探索した関連ソース(該当コード / テーブル / docs)を突き合わせて、根本原因を推定してfix PRを生成する
• 維持ループ: 生成されたfix PRはcortex-product-graphを文脈基盤としたAIレビューフローで品質担保されてからマージされる
• ハルシネーション閉じ込めの実装: AIが本番環境に直接触れない設計。AIの出力は常に「PR」というreview可能な形。cortex-product-graph + AIレビュー + auto-merge chainが最終ゲートとして機能する

これがAI-Native Redesignの循環構造の完成形。監視 → 検知 → AI推論 → PR生成 → AIレビュー → マージ、という1本のループ全体が回ることで、cortexは「気づく前に直る」状態になっている(Self-Healing記事のタイトル通り)。

5実装の共通パターン

これら5つを組み立てる過程で、意識的に共通させてきた設計判断があります。

• 作成側は基本的に決定論: 静的解析、ORM、OTel、SQL、抽出パイプラインといった書かれた通りのデータを扱う部分は決定論に寄せる
• AIは消費側と、構造化の意味付け部分に限定: グラフ探索、意味的検索、annotation生成のような、ルールでは書き下せない判断だけをAIが担う
• ハルシネーション閉じ込めの仕掛けが必ずある: boundary node、AIレビュー、人間レビューなど、システムごとに違う形でAIの出力に「蓋」がかかる。AIが自由に出力できる領域を狭めつつ、出力した内容にも必ずレビュー層を通す
• AIレビューの品質は文脈基盤の整備に依存する: cortexで包括的なPRレビューをAIが担えるのは、cortex-product-graphという構造化された文脈基盤があるから。cortex-product-graphがなければ、AIはPR diffの局所的な情報しか見えず、コード全体との整合性やドキュメントとの一貫性は判断できない。「AIをどこにどう使うか」より前に、「AIが判断できる文脈をどう作るか」が問われる
• レビュー方式の選択にはリスクプロファイルも入る: AIレビューで十分な精度が出せるとしても、間違ったときの影響が大きい対象は人間レビューを選ぶことがある。db-graphで述べた通り、間違いのコストと人手のコストを比較して判断する
• 人の設計判断が上位に残る: スキーマ設計(biz-graph)、ガイドライン定義(auto-review)、監視対象の選定(Observability)は人が行う

同じ「AI-Native Redesign」の原則が、対象と目的に応じて異なる形で実装されている、というパターンが見えるはずです。

AI-Native Redesign vs 「AIツール追加」

これまで見てきたのは、AIが決定論では届かなかった領域を初めてカバーできるようになったこと、そしてそれを機能させるには文脈基盤(cortex-product-graph)や循環構造(Observability + Self-Healing)といった全体設計が必要だということ。

この章では、その全体設計をせずに「既存システムにAIを追加する」だけで済ませようとするアプローチがなぜ失敗するかを掘り下げます。

「AIツール追加」の典型パターン

昨年、私自身も組織に様々なAIツールを入れてきました。以下は、その過程で全部一度は試してきたパターンです:

• ダッシュボードにAIサマリー機能を追加: AIがダッシュボードを見て要点を教えてくれる
• ドキュメントをAIで自動生成: コードからドキュメントを生成する
• PRレビューにAIを追加: AIがPRを見て指摘する
• 社内ナレッジベースにAI検索を追加: 自然言語でナレッジを検索できる
• コーディングにAIアシスト: Claude Code、Cursor等で生産性を上げる

もちろん個別には有用でした。でも成果はせいぜい1.x倍程度に留まり、導入コストには見合うものの、パラダイムシフトが起きるようなレベルには到底届かなかった、というのが正直な実感です。

だからこそ、組織としてAIをもっとうまく使うにはどうすべきか、あらためて考え直すことになりました。そのときに見えたのが、これから述べる3つの理由と、そこから導かれるAI-Native Redesignの方針です。

失敗理由1: 既存の3ノードバランスが人手前提のまま残る

既存システムは、その時代のcapabilityの中で3ノードを「人手が扱うこと」を前提に最適化してきました。

• ダッシュボード: 人が見ることを前提に情報密度と件数が決まっている
• ドキュメント: 人が読むことを前提に構造と粒度が決まっている
• コード: 人が書き、人がレビューすることを前提に規約や粒度が決まっている

そこにAIを足すと、「人手前提のバランス」の中でAIが動くことになる。AIが本来持つ能力(大量のダッシュボードを同時に見る、ドキュメントを構造的にたどる、コードを網羅的に検証する)を活かせない。3ノードのうち一箇所にAIが入っただけで、他の2ノードは人手前提のまま。

失敗理由2: 文脈基盤なしにAIが判断させられる

先の実装例で見たように、cortex-product-graphのような文脈基盤があって初めてAIレビューが包括的に機能します。文脈基盤なしにAIに判断させると、局所的な情報しか見えず、AIの本来の価値が引き出せない。

• PRレビューAI: PR diffだけ見て「コーディングスタイル指摘」が精一杯
• ダッシュボードAIサマリー: そのダッシュボードの数値を要約するだけ、システム全体との関係は見えない
• ドキュメントAI検索: キーワードマッチや意味的検索の局所的な結果

「AIが浅い」と感じるのは、多くの場合AIそのものの問題ではなく、判断のための文脈基盤が用意されていないからです。

これは近年context engineeringと呼ばれるようになった議論と隣接しています。検索側の設計は以前agentic Graph RAGの記事で書きましたが、3ノードループの視点で見るとcontext engineeringは消費側の一部でしかありません。ここで起きている失敗はもっと上流、作成側が引ける形を作っていないことにあります。

失敗理由3: 「AIが消費できる形」への作成側の変更が起きない

先に述べた3方向のシフトのうち、方向1(タイプ1の残された定性判断ノードを自動化)は既存システムにAIを足すだけで達成できます。でも方向2(構造化システムを作るコストを下げる)と方向3(構造化データを意味的に消費する)を活かすには、作成側で「AIが消費しやすい形」への変更が必要です。

• コードにJSDoc @graph-* を付けて、構造とビジネス意図をSSoT(Single Source of Truth: 唯一の信頼できる情報源)として表現する → AIが構造と意図の両方を統合的に理解できる
• ログを構造化イベントとして吐かせて、別サービスのtrace / metricと関連付ける → AIが分散システムを横断して因果関係をたどれる
• ドキュメントを個別ファイルではなく、コードや設計、ドメインなどと関連付けたデータとして構造化する → AIが文脈として引ける

これらは作成側の設計変更で、既存システムに機能追加するだけでは実現しない。「AIを消費側に足す」だけでは、AIの能力が入力側の制約(粗い形式、暗黙の文脈、局所的な情報)で頭打ちになる。

AI-Native Redesignとは何か

3つの失敗理由を裏返すと、AI-Native Redesignがやることが見えます:

• 3ノード全体を「AI + 人」前提で再バランス: どのノードにAIを配置し、どこに人を残すかを再設計する。「人手前提のバランス」に「AIを足す」のではなく、「AIが担うノード」を含めた新しいバランスを描く
• 文脈基盤を先に構築: AIが判断のために引ける構造化された文脈(cortex-product-graphのようなもの)を先に整備してから、その上にAIレビューや自動修復を載せる。「AIを載せてから文脈が足りないと気づく」の逆順
• 作成側の変更を伴う: AIが消費しやすい形への作成側の変更(annotation、構造化イベント、細粒度ドキュメント等)を含む。消費側だけの追加では不十分

先に見たcortexの5実装は、どれもこの3つを実践してきました。code-graphは静的解析でAIが引ける形の構造を作った(作成側の変更)。cortex-product-graphは判断のための文脈基盤そのものになった。Observability + Self-Healingは監視から自動修復まで3ノード全体をAI含みで再設計した。

これが次章で描く「進化速度の差が広がっていく」風景の原因構造だと考えています。「AIツールを追加」と「AI-Native Redesign」の差は、投資対効果が線形と指数の違いにとどまらないように感じています。

AI-Native Redesign後の風景

cortexを組み立てて実感していること

cortexを組み立てて回している中で、単発のAIツールを入れていた時期には見えなかったことがいくつか見えてきました。

• fix PRがAIから生成されて、そのままAIレビュー → 自動マージへとループに乗る場面が、Self-Healing経由だけで直近30日に115本まで積み上がった(Self-Healing記事参照)
• ドキュメント / annotation / コードのdriftが、以前は放置されていた場所で自動的に修復される
• 「これどうやって作られてるんだっけ？」と過去の設計を追いかけるコストが下がった
• 開発速度そのものは以前と大きく変わっていない。変わったのは、リリースされる品質のバーと、私以外の人が開発に参加できるようになったこと。3月まで月10〜23本だったマージ済PRが4月に518本になった(main push → PR + AIレビュー + 自動マージ へのworkflow転換)のは、「私一人の手作業レビューという上限が外れて、この規模と品質を私以外の人でも捌けるようになった」実体です(ハーネス総論参照)

これは「AIツールを一つ入れたら1.x倍」というレベルではなく、「複数の自己維持するループが多層で回るようになる」効果の実感です。単発の生産性向上とは質の異なる変化に感じています。

自己維持するループが多層で回るとは

これまで挙げてきたcortex実装は、それぞれが独立に自己維持するループを持っています。

• code-graph: コードが変わるたびにgraphが更新され、AIがそれを使ってレビューできる
• cortex-product-graph: PRごとにannotationとコードの整合性が保たれ、AIレビューの精度が上がっていく
• Observability + Self-Healing: 監視でインシデントが検知され、AIがfix PRを生成し、AIレビューを経てマージされる
• biz-graph: 施策とKPIの関係が継続的に抽出され、意思決定に使える形で保たれる

それぞれのループは独立に動いていますが、cortex-product-graphを共有の文脈基盤として繋がっている。あるループの出力が別のループの入力になる、というつながり方をしています。

こういう多層のループが組織の中で回りだすと、時間の使い方が根本的に変わってくる感覚があります。「AIが助けてくれる」というレベルではなく、「日々の作業のかなりの部分がループの中で完結する」に近い。

この構造が腐るとしたら、どこから

3ノードの対称性を軸にする以上、AI-Nativeシステム自身の負のスパイラルも問うべきです。好循環として提示した循環参照(AIレビューがcortex-product-graphを維持し、cortex-product-graphがAIレビューを支える)は、基盤に誤りが混入した瞬間から誤りを自己増幅するループの構造そのものになります。汚染された文脈基盤の上でAIが自信を持って間違え続ける、という失敗モードは、この設計の対称的な弱点として実在します。

対処は3層に書き分けています。db-graphで人間レビューを最終ゲートに置いているのは、リスクが大きい箇所で基盤への汚染流入を絞る「入り口」の防衛。boundary nodeを静的解析で明示化しているのは、AIの推論範囲を狭める「制御」の防衛。cortex-product-graph自体を、決定論的な抽出 + annotation + docsから常に再生できる形に保っているのは、汚染に気付いたときに戻せる「復旧」の防衛です。いずれも「AIが単独で書き足すだけの基盤にしない」という思想でつながっています。顕在化の兆候は、AIレビューの精度指標(REQUEST_CHANGES率、false positive / negative率)が説明できない仕方でドリフトする形で現れるはずで、これがAI-Observability記事で「LLMを監視の第4軸に含めるべき」と書いた理由の対称面での延長です。

進化速度の差についての見立て

ここから先は私の見立てで、他組織にどう当てはまるかはわからない話です。

なお「これは専任のプラットフォームチームがある組織の話では」と思われるかもしれませんが、airClosetにそんなチームはありません。cortexは私一人がCTO業務と並行して組んできたもので、今はそのハーネスの上でビジネスサイドを含めた人たちが開発に参加できるようになっています。それが可能だったこと自体が方向2(AIが構築コストを下げる)の実例です。

AIツールを単発で入れている組織と、多層の自己維持するループを組み上げている組織とで、時間が経つほど組織の進化速度に差が出るのではないかと感じています。

• 前者ではAIが便利ツールとして存在するけれど、意思決定と実装のスピード自体は大きくは変わらない
• 後者では意思決定 → 実装 → 検知 → 修正のサイクル全体が桁違いに速くなる

その差が時間とともに累積すると、同じ期間で実現できることの量が徐々に(あるいは急激に)変わってくる。「指数関数的に」と言ってしまうと言い過ぎかもしれませんが、少なくとも線形の差では説明できないような広がり方をするのではないか、というのが私の見立てです。

この記事で言いたかったこと

普遍の問い、「正確な情報に、適切にアクセスできるようにするには？」を、AIという新しい能力を前提に再設計する。これがAI-Native Redesignの中心にある考え方です。

• AIは決定論的自動化の代替ではなく、決定論が届かなかった領域を初めて自動化の射程に入れる新しい能力
• AIを個別に足すのではなく、3ノード全体を組み立て直すことで、初めて正のスパイラルが回る
• そのためにはAIが判断できる文脈基盤(cortex-product-graphのようなもの)を先に整備する必要がある
• 全体は自己維持するループの積み重ねで、多層に回るほど組織の進化速度が変わってくる

最後に、本稿では射程を「情報アクセス」に絞りましたが、作成 / 維持 / 消費の3ノードで回る営みは、実はもっと広くに現れます。文化の継承も、事業の存続も、学問分野の発展も、言語そのものすら、消費されなければ作成の動機が枯れ、維持されなければ消費に耐えなくなる、という同じ構造で回っている。死語も、廃れた伝統も、潰れた事業も、誰も読まない社内wikiも、突き詰めれば同じメカニズムで空洞化してきました。だとすれば、「AIが作成・維持のコストを構造的に下げる」という本稿の主張の射程が、情報システムを超えてどこまで及ぶのか——これは検証しきれない大きな問いとして、ここでは開いたまま置いておきたいと思います。

cortexで実装してきた過程は、この考え方の一つの試行例です。組織や対象は違うでしょうが、根底にある「情報を適切にアクセスできるようにする」という問いは共通のはず。そこにAI-Nativeな答えを描くとどうなるか、という視点を、この記事が他の場面でも当てはめてみるための素材になれば幸いです。