AI 2026年4月24日

AIを「会話ツール」で止めてはもったいない——ワークフロー型AIという考え方

AIを「会話ツール」として使い続けることの構造的な問題

AIを毎日使っているのに、なんとなく疲れる。同じような質問を何度もしている気がする。そんな感覚、ないだろうか。

Zennに興味深い記事が上がっていた。Andrej Karpathyの提案をベースに、AIの使い方を「会話型」から「ワークフロー型」へと転換することを論じたものだ。実装の話ではなく、AIとの付き合い方そのものの設計思想について整理している。

現在の主流であるChatGPT・Claude・Geminiなどのチャット利用には、構造的な限界が3つある。

ステートレス：スレッドを閉じれば文脈は消える。永続的な知識にはならない
暗黙的な個人化：メモリ機能は便利だが、何が記憶され何が忘れられたかが外から見えない
成果物が残らない：会話ログは残るが、「整理された知識」としてリユースできる形ではない

この3つが重なると、「AIを使っているのに毎回ゼロからコンテキストを説明している」という状態になる。便利なはずのツールが、なぜか疲労感を生む原因はここにある。

Andrej Karpathyが提唱した「知識コンパイラ」という発想

この問題に対してKarpathyが提案したのが、LLMを「知識コンパイラ」として使う発想だ。彼の主張を一言で言えばこうなる。

LLMへのトークン支出を、「コードを書く」用途から「知識を操作する」用途へ意識的にシフトすべきだ。

具体的には、クリップした記事・走り書きのメモ・Slackの会話・論文PDFといった生の素材をLLMに読ませ、概念ページ・エンティティページ・ソースサマリーという構造化されたMarkdown Wikiに変換する。プログラミングのコンパイラが「ソースコード→実行可能バイナリ」を生成するのと同じメタファーで、「非構造化データ→構造化知識」を生成するわけだ。

さらに、一度作った知識ベースは放置すると陳腐化する。そこで「知識リンティング」という概念も提案している。LLMに定期的にWikiを読ませ、矛盾する記述の検出・リンク切れの修正・「最新」「現在」といった表現が90日以上前を指していないかのチェック・重複ページの統合、といったメンテナンスを自動化する。コードベースにおけるlinterやCIと同じ役割だ、という整理は腑に落ちる。

会話型 vs ワークフロー型：何が変わるのか

記事では両者を7つの観点で比較している。整理すると以下のようになる。

観点	会話型AI	ワークフロー型AI
中心的な操作	質問→回答	素材→コンパイル→維持
状態	ステートレス	知識が蓄積
個人化	暗黙的（メモリ機能）	明示的（Markdownファイル）
検査可能性	低	高
バージョン管理	基本的にできない	Gitで可能
成果物	会話ログ	構造化された知識ベース
アクセス経路	当該ツールのUI経由	任意のエディタ・スクリプト

ここで重要なのは、会話型が劣っているという話ではないという点だ。アドホックな質問には会話型が向いている。蓄積されて資産になる知識はワークフロー型に寄せるべき。両者は排他ではなく補完関係として使うのが現実的な落とし所だ。

AIおじさんとして気になった「外在化・検査可能」という視点

この記事でいちばん刺さったのは、「個人化を外在化・検査可能にする」という論点だ。

ChatGPTのメモリ機能やClaude Projectsは便利だが、何が覚えられているのか、古くなった情報をどう削除するのか、利用者から見て不透明になりがちだ。「AIの回答が微妙だったとき」、その原因がプロンプトの問題なのか、参照した知識の問題なのか、モデル自体の限界なのか——内部状態がブラックボックスだと、切り分けそのものができない。

Markdownファイルとして外在化しておけば、「このページの情報が古かった」「このページに偏りがあった」と具体的に指摘できる。これは地味なようで、運用上かなり大きな差になる。

もう一つ見逃せないのがツールロックインの問題だ。ChatGPTのメモリに蓄積した情報は、Claudeに引っ越すときには持ち込めない。Markdownという汎用フォーマットで外在化しておけば、ツールが変わっても知識は残る。これを「長期的な資産性」と呼んでいるが、次の世代のモデルやエージェントへの移行コストを考えると、いま設計しておく価値はある。

チーム・組織レベルへの広がりについても言及がある。個人のメモリ機能は他人に共有できないが、Markdownファイルは、GitHubにpushすればチームメンバーが読め、プルリクエストでレビューでき、履歴も追える。「個人の暗黙知」から「チームの明示知」へ昇格させる仕組みとして機能する。

実務的にどう始めるか：3レイヤーの考え方

記事では個人・チーム・組織の3レイヤーで適用できると整理している。

Layer 1（個人） から始めるのが現実的だ。最小構成はMarkdownを管理できるエディタ（Obsidianなど）・Gitリポジトリ・AIエージェント（Claude Code等）の3点。記事の著者自身はObsidian Web Clipper＋Claude Code Skills＋Claude Code Routinesによる半自動パイプラインとして数週間運用し、「会話の流れに溶けて消えていた知識が、外在化・検査可能な形で手元に残り始める」感覚を実際に得ている、と書いている。

Layer 2（チーム） では、Wikiを共有リポジトリとして持ち、エンジニア向け・カスタマーサポート向け・PM向けといった役割別のエージェントがそれぞれ参照する構成になる。共通の知識レイヤーを土台に置けば、「エージェントAとエージェントBで矛盾した回答が返ってくる」という運用上の悩みを構造的に減らせる可能性がある。

Layer 3（組織） まで広がると、知識ベースのオーナーシップ定義・定期的なリンティングのスケジュール化・Git履歴による更新者の追跡が必要になる。これはもう「AIを導入する」という話ではなく、「AIが読める形に組織知を再編成する」という設計判断だ。ただし、フォーマットの統一・品質管理のゲート設計・機密情報の取り扱いを設計せずにingestだけ回すと、低品質なページが増えるという問題も出てくる。留保として明示されている点は素直に受け取っておいた方がいい。