見出し画像

AIが常に自分のことを知っている状態を作る — 全体設計

Hayate Takeda

自己紹介：こういう仕事をしている

ソフトウェアエンジニア、実務2年目。
GISシステムや電力インフラ・製造業のDXを中心に、設計・実装・提案をひとりでこなす場面が多い仕事をしている。

複数の案件を並走しながら、それぞれに違う技術スタック・違うドメイン知識・違うステークホルダーとやり取りする。
今週はTypeScriptを触り、来週は.NETでAPIを書き、再来週はシステム提案資料を作る、みたいな働き方だ。

こういう働き方をしていると、AIツールへの期待と不満が人一倍大きくなる。
期待は「これだけ複雑な仕事を助けてくれるはず」という期待。
不満は「でも毎回ゼロから説明している」という現実。

こういう問題があった

Claude、ChatGPT、Cursor。いろんなAIツールを使ってきた。
どれも賢い。
でも毎回同じことに引っかかる。

「また最初から説明している」

たとえばこういうシーンがある。
新しい案件でAIに設計の相談をしようとする。
まず技術スタックを説明する。
チームの体制を説明する。
前提となるドメイン知識を説明する。
「前の案件でこういう失敗をして、だからこういう設計方針にしたい」という経緯も説明する。

これだけで相当な時間がかかる。
しかもこれ、前回のセッションでも同じことをやった。

AIは「自分の仕事の文脈」を何も知らない。
自分がどういう設計思想を持っていて、どんな失敗から学んできたか。
どの技術スタックが得意で、どの判断パターンが自分らしいか。
AIにとって自分は、毎回初対面の他人だ。

ツールは賢くなっているのに、「自分のことを知っているAI」にはなっていなかった。

目指したビジョン

ある時点から、発想を変えた。

AIに「答えを聞く」のをやめて、AIが動く基盤を作るという方向に切り替えた。

「AIが常に自分のことを知っている状態」を作れないか。
セッションをまたいでも、案件をまたいでも、自分の文脈をそのまま引き継いで動くAI。
毎回ゼロから説明するのではなく、「自分の過去の判断・学び・文脈」を知った上で動いてくれるAI。

それはツールを上手く使うという話ではなく、AIが動くOSを自分で作るという話だった。

既存ツールで足りないもの

各ツールが何をできて、何ができないかを整理すると、構造的な空白が見えてくる。

どれも「部分」は優れている。
Cursorはコードを書く力が高い。
Claude.aiは推論が深い。
Obsidianは知識の整理ツールとして完成している。

でも「自分の文脈を知った上で動く」という部分は、どのツールも担っていない。
足りないのは各ツールの性能ではなく、全部を繋ぐ基盤だった。

Orbitという解答

行き着いたのは、Obsidian × Claude Code の組み合わせだった。

Obsidianは知識の器として使う。
すべてのデータがテキストファイルとMarkdownで構成されているから、AIが直接読める。
データベースもAPIも要らない。
ファイルを置くだけで、AIのコンテキストになる。

Claude Codeはリポジトリ全体をコンテキストとして扱いながら動く。
「このディレクトリにある知識をすべて前提にして動いてほしい」という指示が自然にできる。

この2つを同じファイルシステム上に置く。
ObsidianのVaultとClaude Codeのワーキングディレクトリを一致させる。
それだけで、「AIが読める知識基盤」ができあがる。

専用のAPIも、複雑なベクトル検索も、外部サービスとの連携も要らない。ただのファイルシステムが、AIの長期記憶になる。
このシステムをOrbitと呼んでいる。

2レイヤー構造

Orbitは2つのレイヤーで構成されている。

┌─────────────────────────────┐
│ Layer 1（上層）: 作業実行   │
│ 計画・設計・ドキュメント     │
└──────────────▲──────────────┘
               │
┌──────────────┴──────────────┐
│ Layer 2（土台）: ナレッジ   │
│ 知識・自分の文脈の蓄積       │
└─────────────────────────────┘

重要なのは、下から積み上がるという方向性だ。
上から降りてくるのではなく、知識という土台の上に仕事が乗る。

各レイヤーを分解するとこうなる。

Layer 2: ナレッジ（土台）
技術知識・ドメイン知識・過去の意思決定・自分の行動パターンを蓄積する層。
AIが「自分のことを知っている」の核心はここにある。

Layer 1: 作業実行（上層）
要件整理・WBS・設計・ドキュメント・提案資料をAIと一緒に作る層。
AIをエージェントチームとして使い、自分はPMとして意思決定だけをする。

作業実行もAIがいれば多くをこなせる。
でもナレッジ——「何を知っていて、どう次回に渡すか」——は既存ツールが最も弱い部分だ。
だからここが土台になる。

全体の循環

2レイヤーは一方向ではなく、循環している。

Wiki参照（ナレッジ）
  ↓
要件定義・設計・実行（作業実行）
  ↓
ADR生成・学びの言語化（ナレッジ更新）
  ↓
次のサイクルへ

たとえば、新しい案件でGISのAPIを設計するとき。
まずWikiで過去の類似設計を参照する。
それを踏まえて要件定義・設計をAIと壁打ちする。
タスクが終わったら「なぜこの設計を選んだか」をADRとして記録し、Wikiに戻す。

次に似た案件が来たとき、AIはこのADRを知っている。
「前回はこういう理由でこの設計を選んだ」という文脈を持った上で、次の設計の相談に乗れる。

このループが回るほど、AIが「自分のことを知っている状態」に近づいていく。
使えば使うほど賢くなる——正確には、使えば使うほど自分のことを知るようになる、という設計だ。

この記事シリーズについて

この記事はシリーズの1本目として、Orbitの全体像を説明した。
今後は、以下の記事を投稿する予定。

記事2 ナレッジ基盤編
知識をどう設計・蓄積・参照するか
3_Wikiと4_Contextの設計思想、ingest/queryのワークフロー

記事3 作業実行エージェント編
仕事をどうAIエージェントチームで回すか
PMゲート・2レーン実行・レビュー設計

設計思想と実装の構成をそのまま書いている。
「自分も組んでみよう」と思ったら、そのまま叩き台として使ってみてほしい。

いいなと思ったら応援しよう！