ryantsuji.dev

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

29 min read

目次

  1. 不変の原理
  2. 3つのノードに分けて考える
  3. 変わってきたもの、変わっていないもの
  4. 各ノードを詳しく見る
  5. 3ノードの負のスパイラル — なぜ多くの現場で崩壊するのか
  6. この記事の残りで何をやるか
  7. 決定論では手が届かない領域
  8. タイプ1: 特定ノードに人手依存が残っている分野
  9. タイプ2: 作るコストが消費メリットに見合わなかった領域
  10. タイプ1とタイプ2の違い
  11. 共通するパターン
  12. AIが決定的な転換である理由
  13. AIの本質的に新しい部分
  14. 3方向のシフト
  15. 決定論優先の原則
  16. なぜ「AI前提の設計」が必要なのか
  17. cortexでの実装例
  18. code-graph
  19. db-graph
  20. biz-graph
  21. cortex-product-graph
  22. Observability + Self-Healing
  23. 5実装の共通パターン
  24. AI-Native Redesign vs 「AIツール追加」
  25. 「AIツール追加」の典型パターン
  26. 失敗理由1: 既存の3ノードバランスが人手前提のまま残る
  27. 失敗理由2: 文脈基盤なしにAIが判断させられる
  28. 失敗理由3: 「AIが消費できる形」への作成側の変更が起きない
  29. AI-Native Redesignとは何か
  30. AI-Native Redesign後の風景
  31. cortexを組み立てて実感していること
  32. 自己維持するループが多層で回るとは
  33. この構造が腐るとしたら、どこから
  34. 進化速度の差についての見立て
  35. この記事で言いたかったこと

みなさまこんにちは！エアークローゼットで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ノードループの負のスパイラルと正のスパイラルの対比 — 人手前提のバランスで組み立てた仕組みは「やらない理由」が相互補強される負のスパイラルに落ちる。AI前提で組み立て直すと3ノードそれぞれをAI × 決定論のハイブリッド(各ノードでAIが担う範囲は設計判断、決定論優先)として再構成することで、自己維持する正のスパイラルになる

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

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

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

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

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

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

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

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

分野 作成 維持 消費
業務ドキュメント 人手(仕様/design doc/runbook) 人手(追従更新) 人手(読む)
監視(Observability) 自動(APM/log/metrics) 自動(※metric定義の変更のみ人手) 人手(dashboard判断・改善サイクル)
業務データ(BIレポート) 自動(SQL/ETL) 自動(※schema変更のみ人手) 人手(分析・解釈)
スキーマ管理(基本CRUD) 自動(ORM生成) 人手(migration判断) 自動(validation)
セキュリティ体制 自動(log/anomaly detection) 自動(※rule更新のみ人手) 人手(脅威判断・alert選別)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

タイプ1とタイプ2の対比 — タイプ1は既存フローの真ん中(人手判断)がAIで拡幅されるボトルネック解消。タイプ2はバラバラだった点(コード / テーブル / 施策 / KPI等)をAI + 決定論が意味的な網の目に織り上げる未探索領域の開拓

共通するパターン

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

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

これが次に扱う「AIが画期的な理由」の直接の前提になります。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をどこに使うかは意思決定です。「AIならなんでもできる」わけではなく、決定論で書ける部分は決定論で書いて、決定論では書けない残りの部分だけをAIに任せる。この分担設計がAI-Native Redesignの核心にあります。

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

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

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

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

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

cortexでの実装例

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

code-graph

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

db-graph

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

biz-graph

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

cortex-product-graph

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

Observability + Self-Healing

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

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

5実装の共通パターン

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

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

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

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

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

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

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

もちろん個別には有用でした。でも成果はせいぜい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の本来の価値が引き出せない。

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

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

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

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

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

AI-Native Redesignとは何か

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

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

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

AI-Native Redesign後の風景

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

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

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

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

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

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

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

多層の自己維持するループ — cortex-product-graphを共通の文脈基盤に、code-graph / db-graph / biz-graph / Observability + Self-Healingの各ループが互いを支え合う。Self-HealingではAI推論(Grafana MCPのログ + cortex-product-graph)とAIレビュー(cortex-product-graph参照)を経て人間を介さずにループが閉じる

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

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-Native Redesignの中心にある考え方です。

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

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

comments (0)

まだコメントはありません。