前回の記事では、Devin CLI が参照する wiki の正体を調べた。結論は「DeepWiki が生成した wiki を、CLI 起動時に ~/.local/share/devin/cli/wiki/ へダウンロードするローカルキャッシュ」だった。鮮度には2段階の遅延があり、ローカルファイルの mtime は「ダウンロード時刻」であって「生成時刻」ではない、という罠もあった。
では、ブラウザから使うクラウド版の Devin セッションはどうなのか。同じ DeepWiki を参照しているはずだが、CLI のようなローカルキャッシュの構造はあるのか。今回は Devin 本人（クラウド版セッション）に自分の環境を調査させて、実際のツール挙動を確認した。
この記事でわかること
- クラウド版 Devin が wiki にアクセスする手段（CLI とは根本的に違う）
- 鮮度モデルの違い。CLI の「2段階の遅延」のうち、クラウド側には存在しない段階がある
- 両者に共通する「wiki は地図」という参照運用
前提
| 項目 | 内容 |
|---|---|
| 環境 | クラウド版 Devin セッション（Web から起動、Linux VM 上で動作） |
| wiki アクセス経路 |
devin_mcp ツール群（サーバーサイドの DeepWiki を参照） |
| 対象リポジトリ | GitHub 上のプライベートリポジトリ（前回と同じ kinopeee/interpreter-openai） |
全体像
先に結論の図を出す。CLI は「起動時にダウンロードしてキャッシュ」、クラウドは「呼び出しごとにサーバーへ問い合わせ」。生成元の DeepWiki は共通だ。
見てほしいのは、クラウド側にはローカルキャッシュに相当する箱がないことだ。VM 上に ~/.local/share/devin/cli/wiki/ のようなファイルは存在せず、ツール呼び出しのたびにサーバーサイドの DeepWiki を直接参照する。
クラウド側の実物: ツール一覧
調査してもらったところ、wiki 関連で使えるツールはこれだけだった。
| ツール | 役割 |
|---|---|
read_wiki_structure |
リポジトリの wiki 目次（ページ一覧）を取得する |
read_wiki_contents |
wiki の本文を読む |
ask_question |
リポジトリへの質問に、wiki ベースで根拠付きの回答を得る |
generate_wiki |
wiki の生成・再生成（ユーザーが明示的に依頼したときのみ） |
list_available_repos |
wiki 問い合わせ可能なリポジトリの一覧 |
面白いのは read_wiki_structure だ。前回の記事では、CLI のエージェントが ^#{1,4} という正規表現で Markdown 見出しを検索して「目次にあたる部分」を掴んでいた。クラウド側ではそれが専用ツールとして切り出されている。やっていることは同じで、実装が違う。
実測: 目次の取得
実際に read_wiki_structure を kinopeee/interpreter-openai に対して呼んだ出力がこれだ（抜粋）。
Available pages for kinopeee/interpreter-openai:
- 1 Overview
- 1.1 Getting Started
- 1.2 Application Lifecycle and Entry Point
- 2 Core Architecture
- 2.1 AppCoordinator: Central Orchestrator
...
- 4 OpenAI Realtime API Integration
- 4.1 DualRealtimeTranslationClient
...
- 15 Glossary
番号付きのページツリーが返る。「まず構造だけ掴む」という使い方がツールの形そのものになっている。
実測: 質問応答
ask_question に「What is the role of DualRealtimeTranslationClient?」と聞いたところ、こう返ってきた（抜粋）。
The
DualRealtimeTranslationClientacts as the central orchestrator for interactions with the OpenAI Realtime API, managing concurrent WebSocket connections to provide simultaneous transcription and translation of audio. It handles complex audio routing, fault tolerance, and event merging from multiple connections into a single stream.
定数（translationPrerollFrameLimit = 40 frames など）や主要メソッド一覧まで具体的に列挙され、最後にこう続いた。
Wiki pages you might want to explore:
- DualRealtimeTranslationClient (kinopeee/interpreter-openai)
View this search on DeepWiki: https://app.devin.ai/search/...
回答そのものだけでなく、参照した wiki ページと DeepWiki 上の検索へのリンクまで付く。CLI 側の changelog にあった「explore subagent を使って回答する」に相当する機能が、クラウド側では ask_question という1つのツールにまとまっている形だ。
決定的な違い: キャッシュの段階がない
前回整理した CLI の鮮度モデルはこうだった。
- 1段階目の遅延: DeepWiki の索引サイクル（Weekly なら最大約1週間）
- 2段階目の遅延: ローカルへのダウンロードが CLI 起動時にしか走らず、しかも利用は「後続のセッションから」
クラウド側では2段階目が存在しない。
従ってクラウド側で意識すべき鮮度の罠は1つだけだ。
- ある: DeepWiki の索引サイクルによる遅延（Weekly なら最大約1週間、未 push のローカルコミットは乗らない）
- ない: 「ダウンロード時刻の mtime を生成時刻と読み違える」罠。そもそもローカルにファイルがない
- ない: 「CLI を起動しっぱなしだと古い wiki を見続ける」問題。セッション中の呼び出しは毎回サーバーへ行く
前回の記事で自分がやらかした「mtime を見て『ほぼ最新だな』と思い込む」ミスは、クラウド側では構造上起きえない。
比較表
| 観点 | Devin CLI | クラウド Devin セッション |
|---|---|---|
| wiki の生成元 | DeepWiki（サーバーサイド） | DeepWiki（サーバーサイド） |
| ローカルキャッシュ |
~/.local/share/devin/cli/wiki/ に保存 |
なし。呼び出しごとに問い合わせ |
| 取得タイミング | CLI 起動時にバックグラウンド | ツール呼び出しのたび |
| 利用開始 | ダウンロード後の後続セッションから | そのセッション内で即時 |
| 鮮度の遅延 | 2段階（索引 + ダウンロード周期） | 1段階（索引のみ） |
| mtime の罠 | あり（ダウンロード時刻を示す） | なし（ファイルが存在しない） |
| 目次の取り方 |
^#{1,4} などで wiki を検索 |
read_wiki_structure 専用ツール |
| wiki ベースの Q&A | explore subagent 経由（環境設定で変動） |
ask_question ツール |
| 索引されていない場合の見え方 | ローカルに wiki が作られない |
list_available_repos に載らない |
| wiki の再生成 | DeepWiki 側の設定/操作 |
generate_wiki（明示的な依頼時のみ） |
共通点: 「wiki は地図」の2段構え
違いばかり書いたが、使い方の芯は同じだった。クラウド側のエージェントもこう動く。
クラウドのセッションでも対象リポジトリは VM にクローンされているので、照合先のコードは手元にある。「wiki はあくまで地図で、回答の根拠にはしない」という運用は CLI と共通で、この2段構えのおかげで wiki が多少古くても誤回答に直結しにくい。
そもそも wiki 機構のメリット
古さのリスクを書いてきたが、この機構が存在するのは当然メリットがあるからだ。
- 探索の初手コストを下げる: 大きなコードベースを全部読むことは現実的に不可能で、grep だけでは「どこから調べるか」の当たり自体が付かない。目次 → 該当ページという2段アクセスで、読む量を桁違いに減らせる
- 構造の理解が先に得られる: ファイルツリーからは読み取りにくい、コンポーネント間の関係や設計の意図が要約されている。「アーキテクチャはどうなっている？」という概念レベルの質問にも答えられる
-
クローンせずに聞ける: 手元にチェックアウトしていないリポジトリでも、
ask_questionで質問できる。自分の環境では15リポジトリが問い合わせ対象になっていた - 古い地図でも地図なしより速い: 1週間古い構成図を起点に照合するコストは、ゼロから全探索するコストより普通はずっと小さい
つまり wiki は「多少古くても、広いコードベースへの理解の助けになる索引」として価値を持つ。鮮度の罠は、このメリットを殺すほどの問題ではなく、運用で吸収できる範囲にある。
古い wiki は誤情報になりうるか
可能性はあるが、実害は限定的だ。理由は前節の2段構えで、回答前に必ず実コードを照合するため、古い地図がそのまま誤回答になる経路は構造上細い。残るリスクは誤情報そのものより副作用の方が大きい。
- 初手の遠回り: リネーム・削除済みの構成を起点にしてしまい、照合で差分を吸収する手間が増える
- 新規要素の見落とし: 索引後に追加された機能は wiki に載らないので、「プロジェクト全体を調べて」系の質問で当たりが漏れやすい
-
照合の省略:
ask_questionの回答を検証なしで採用する使い方をした場合に限り、古い内容が誤情報になり得る
つまり「鮮度が古い＝調査コストの増加＋見落としリスク」であり、誤情報に直結するのは照合を省略したケースだけだ。ここでも対処は同じで、索引サイクルを短くするのが一番効く。
つまずきやすいポイント（クラウド版）
| 罠 | 実際 | 対処 |
|---|---|---|
| 「wiki は最新」と思い込む | 索引サイクル依存。Weekly なら最大約1週間古い | DeepWiki の Last updated を見る。鮮度重視なら Auto-indexing を Daily に |
| 未 push の変更が wiki にあるはず、と思う | 索引対象は GitHub 上のリポジトリ | push して次回索引を待つ |
| wiki ツールが動かない / 構造が取れない | DeepWiki 側で索引されていない | DeepWiki で索引を有効化。list_available_repos で対象か確認 |
| wiki を再生成させたい |
generate_wiki は明示的な依頼時のみ呼ばれる |
「wiki を再生成して」と明示する |
まとめ
クラウド版 Devin の wiki は「DeepWiki への毎回問い合わせ」で、CLI の「起動時ダウンロード + ローカルキャッシュ」とは構造が違う。その分、クラウド側では「ダウンロード周期による遅延」「mtime の読み違い」「起動しっぱなしで古いまま」という第2段階の罠がすべて消える。残るのは DeepWiki 側の索引サイクルという共通の1段階だけだ。
目次を掴む → 本文を読む → コードで照合する、という「wiki を地図として使う」運用は両者で同じ。違いは経路の実装であって、使い方の思想ではなかった。
鮮度が気になる場合の対処も前回と同じ結論になる。DeepWiki のリポジトリページで Last updated と Auto-indexing を確認し、週次のままなら Daily に変える。それが一番手っ取り早い。
なお、この記事はクラウド版 Devin セッションが自分自身のツール構成を実際に呼び出して確認した結果を、記事の形でまとめたものです（＋私の編集）。
前編はこちら: Devin CLI はどのように Wiki を利用するか。DeepWiki キャッシュの仕組みと鮮度の罠