Devin CLI にコードベースのリファクタリング候補を調べさせていたとき、ツールコールのこの部分に目が止まった。
Searched wiki for `^#{1,4}` in kinopeee/interpreter-openai
^#{1,4} は Markdown の見出しを拾う正規表現だ。つまりエージェントは、コードを読む前に wiki の目次にあたる部分を検索して、構成のあたりを付けていたことになる。そもそもローカルのどこに wiki があるのか、誰が生成しているのか。気になってファイルシステムとドキュメントを掘ってみたら、想像と違う構造が見えてきた。
正体は、Devin 側の DeepWiki が生成した wiki を、CLI 起動時にダウンロードしてキャッシュしているものだった。しかもローカルファイルの更新時刻は鮮度を示さない、という罠もあった。実際の挙動を確認した記録として残しておく。
この記事でわかること
- Devin CLI が参照する wiki の生成元と保存場所
- ローカルファイルの更新時刻が「ダウンロード時刻」であって「生成時刻」ではないこと
- wiki の鮮度を確認する方法と、古い wiki を参照させないための実際の運用
前提
| 項目 | 内容 |
|---|---|
| OS | macOS |
| ツール | Devin CLI（3000.10.21）、DeepWiki |
| 対象リポジトリ | GitHub 上のプライベートリポジトリ |
全体像
見てほしいのは、生成の責任が Devin 側（DeepWiki）にあり、ローカルは単なるキャッシュだという点だ。自分のマシンでコードを解析しているわけではない。
ローカル側の実物
まず手元に何があるかを見た。wiki はリポジトリごとのハッシュ名ディレクトリに置かれている。
$ ls ~/.local/share/devin/cli/wiki/a70d5d9e.../
meta.json
wiki.md
meta.json の中身はこれだけだ。
{
"repo_identifier": "github.com/kinopeee/interpreter-openai",
"wiki_id": null,
"version": null,
"title": null
}
repo_identifier が GitHub のリポジトリを指している。つまり索引の対象は GitHub 上のリポジトリであり、未 push のローカルコミットは原理上 wiki に乗らない。
生成元は DeepWiki
根拠は Devin CLI の changelog にあった。v2026.4.24-1（2026-04-24）の記述だ。
When opening the CLI inside a repo that has a Devin wiki, the wiki is now downloaded in the background and made available to the agent on subsequent sessions, so it can answer project questions using an explore subagent.
「Devin wiki を持つリポジトリで CLI を開くと、バックグラウンドでダウンロードされる」と明記されている。生成は Devin 側の DeepWiki が行い、CLI はそれを取りに行くだけだ。
DeepWiki 側を見ると、索引の設定が確認できる。自分の環境では Auto-indexing が Weekly になっていて、選択肢は Manual / Daily / Weekly / Monthly の4つだった。
画面には「Last updated 3 days ago」と出ていた。つまり、手元にある wiki の内容は3日前時点のリポジトリであり、それ以降のコミットは反映されていない。
ここで重要なのは、changelog の条件文だ。「a repo that has a Devin wiki」、つまり Devin wiki が存在するリポジトリでだけダウンロードが走る。実際、このマシンの ~/.local/share/devin/cli/wiki/ には3リポジトリ分しかなく、どれも DeepWiki 側に wiki があるリポジトリだった。
github.com/kinopeee/interpreter-openai
github.com/<private-repo-1>
github.com/<private-repo-2>
逆に言うと、DeepWiki 側で索引されていないリポジトリで CLI を開いても、ローカルに wiki は作られない。ローカルが自発的にコードベースを解析して wiki を生成する機能は、この仕組みにはない。自分の環境に wiki がない場合は、まず DeepWiki 側でそのリポジトリの索引が有効かを疑うのが早い。
もう1つ、changelog の表現から読み取れる制約がある。「opening the CLI … made available to the agent on subsequent sessions」だ。ダウンロードのトリガーは CLI の起動であり、起動中のセッション内で定期的に再取得する記述はドキュメントにない。しかも「後続のセッションで利用可能になる」という書き方なので、起動時に取ってきた wiki はそのセッションではなく次回以降のセッションで使われる設計らしい。
つまり鮮度の遅延は2段階ある。DeepWiki の索引サイクル（自分の環境では Weekly）による遅れと、ローカルキャッシュが CLI の起動を跨がないと更新されない遅れだ。起動しっぱなしの長時間セッションは、最後にダウンロードされた時点の wiki を見続けることになる。
やらかし: ファイルの更新時刻を生成時刻と読み違えた
ここで正直に書いておきたい失敗がある。調査中、自分はこう判断しかけた。
$ stat -f "%Sm %N" ~/.local/share/devin/cli/wiki/.../wiki.md
Sep 15 12:57:24 2026 ...
$ git log -1 --format="%ci %h"
2026-09-15 12:37:40 +0900 fb1346a
「wiki が 12:57、最終コミットが 12:37。最終コミットの20分後に生成されている。ほぼ最新だな」と。これが間違いだった。ファイルの mtime は wiki がダウンロードされた時刻であって、内容が生成された時刻ではない。実際の内容は DeepWiki の「Last updated 3 days ago」の通り、3日前のスナップショットだった。
タイムスタンプだけ見て「新しい」と思い込むのは、キャッシュ系の調査でやりがちなミスだと思う。鮮度を知りたければ、ローカルファイルではなく DeepWiki 側の Last updated を見るしかない。
エージェント側の参照運用
では、古い可能性のある wiki をエージェントはどう使っているのか。冒頭のツールコールがそのまま答えになっていて、wiki を全文読み込むのではなく ^#{1,4} のような検索で構造だけ先に掴み、そこから必要な部分を読む、という使い方をしていた。聞き取りと実際の振る舞いを合わせると、運用はこうだ。
- プロジェクト全体の質問（「X はどう動く？」「Y はどこ？」）→ wiki で当たりを付けてから、必ず実コードを read / grep で照合してから回答する
- 範囲の狭い質問（「この関数は？」「このエラーの原因は？」）→ wiki を経由せず最初からコードを直接調べる
- wiki はあくまで「地図」で、回答の根拠にはしない
changelog には「explore subagent を使って回答する」とあるが、環境の設定で変わるようだ。自分の環境ではサブエージェントを使わない指示が入っていたため、メインの調査フローの中で照合していた。
この「wiki で当たり → コード照合」という2段構えのおかげで、wiki が多少古くても誤回答には直結しにくい。ただしそれは「当たりの付け方が古い分、調査の初手が少し遠回りになる」程度の話で、根拠を wiki に求めない設計が効いている。
つまずきやすいポイント
| 罠 | 実際 | 対処 |
|---|---|---|
| ローカル wiki.md の mtime が新しい | ダウンロード時刻であり、内容の鮮度ではない | DeepWiki の Last updated を見る |
| 「wiki は最新」と思い込む | Weekly 索引なら最大で約1週間古い | 鮮度重視なら Auto-indexing を Daily に |
| 未 push の変更が wiki にあるはず、と思う | 索引対象は GitHub 上のリポジトリ | push して次回索引を待つ |
| ローカルに wiki 自体がない | DeepWiki 側で索引されていないとダウンロード対象が存在しない | DeepWiki でリポジトリの索引を有効化する |
| CLI を起動しっぱなしにしている | ダウンロードは起動時のみで、利用は後続セッションから | 新しい wiki を反映したいときは CLI を再起動する |
まとめ
Devin CLI の wiki は「ローカルで生成される索引」ではなく、「DeepWiki が生成したものを起動時にダウンロードするキャッシュ」だった。鮮度は DeepWiki 側の索引サイクルと CLI の再起動タイミングの両方に依存し、ローカルのファイル時刻からは分からない。
wiki の参照精度が気になったら、まず DeepWiki のリポジトリページで Last updated と Auto-indexing の設定を確認するのが手っ取り早い。週次のまま放置しているなら、そこを Daily に変えるだけで「古い地図を見せられる」頻度はだいぶ下がるはずだ。
なお、この記事は、私がターミナル上で興味の赴くまま調査した結果を Devin CLI + SWE-2 にブログ記事の形でまとめてもらったものです（＋私の編集）。