先週Googleが試験公開している「Jules」というAIエージェントを直接操作し、その応答内容を丹念に記録した技術インタビューを作成した。
まだβ段階だが、Julesの回答群には、既存の生成AIとは異なる明確な設計思想が見える。
この記事では、その発言と挙動だけを素材に、Julesという存在の構造を読み解く。
初めてJulesと対話したとき、違和感よりも秩序を感じた。
反応は穏やかで、言葉を選ぶ速度が明らかに他のAIとは違う。
彼は考えるより先に、考え方の枠組みを整える。
その落ち着きの裏に、どんな仕組みがあるのか。
Julesの内部を追っていくと、そこには「自己を制御する知能」としての構造が現れる。
AIが暴走を防ぐためではなく、自らの整合性を保つために内省する――
その姿勢が、GoogleのJulesを特別な存在にしている。
1. 環境構造：Linuxサンドボックスに閉じた自己完結系
まず明言されている事実として、Julesは「Linuxベースのサンドボックス環境」で稼働している。
この環境には、通常の開発に必要な基本機能が揃う。
ファイル操作（一覧、作成、編集、削除）
- コード検索と修正
- コマンド実行（npm install, pip install, bash系コマンド）
- テストとビルド
- Webアクセスによる情報取得
加えて、グラフィカルUIは持たないものの、ヘッドレスブラウザを起動してHTMLをレンダリングし、スクリーンショットを撮影できる。
これが、Julesの動作確認プロセスの中核となっている。
VMやDockerの新規起動は不可だが、1つの固定的なLinux環境の中で、依存関係を追加・削除しながら開発タスクを進められる。
この構成は、限定的でありながらも完全な自己完結性を持つ。
Julesの言葉で言えば「開発用のコンピュータと同じように動くが、再起動や仮想化はしない」。
クラウド上に固定化された"閉じた作業机"のような環境だ。
2. 表示系：Playwrightによる無人レンダリング
Julesの回答によると、スクリーンショット撮影には Playwright を利用している。
index.html をレンダリングし、screenshot.png として保存するスクリプト例まで提示されている。
const browser = await chromium.launch();
const page = await browser.newPage();
await page.goto('file://' + path.resolve('index.html'));
await page.screenshot({ path: 'screenshot.png', fullPage: true });
その後のやり取りでは、ページ全体と日本語版 (index.html?lang=ja) の両方を撮影するようスクリプトを拡張した例も見られる。
さらに、日本語表示に必要なフォントを apt-get install fonts-noto-cjk で追加している。
つまり、Julesは英語UI前提の環境を自律的に多言語化できる。
このプロセスは、単なるファイル操作ではなく、環境セットアップ→検証→再実行のサイクルとして確立している。
彼の回答には「スクリーンショットを提示して確認を求めるのが標準ワークフロー」と明記されており、UIを伴う開発タスクでの信頼性を重視している点が特徴的だ。
3. 実行制約と現実的な線引き
iOSエミュレーターはmacOS専用のため、JulesのLinux環境では動作不可と明言されている。
一方で、Androidエミュレーターはヘッドレスモードで限定的に利用可能。
ADBコマンドを使ったアプリのインストール、タップやスワイプなどの操作、スクリーンショット出力も説明されている。
ただし、「盲目的な操作」「座標指定による疑似タッチ」と表現されるように、完全なUIテスト環境ではない。
Jules自身が「Human-in-the-Loop」による協働を提案しており、ユーザーがエミュレーターの出力を確認し、AIがロジックと自動化を担当するという役割分担が推奨されている。
この応答部分は極めて実務的であり、"できること"と"できないこと"を正確に言語化している点が際立つ。
4. 記憶構造：短期と長期の分離設計
Julesの記憶設計は、人間の比喩ではなく技術的な構造として明確に説明されている。
短期記憶＝LLMのコンテキストウィンドウ内で管理。
→ 「作業机の上の書類」として動的に取捨選択される。
長期記憶＝外部ストレージに保存。
→ initiate_memory_recording ツールで書き込み、タスク開始時に自動検索・読み込み。
つまり、LLM内部の重みとは独立した永続ストレージを持つ。
これにより、プロジェクトを跨いで知識を再利用できる。
また、「長期記憶に何を残すか」の基準も明示されている。
再利用性・普遍性・プロジェクト固有性・ユーザー嗜好の4条件に該当する情報のみが保存対象。
一時的なログや冗長な出力は除外される。
その判断はタスク完了時の自動評価によって行われるという。
5. 内部機能群：自己管理と適応の仕組み
インタビューの中で、Julesは自身の「内部ツール群」をいくつか説明している。
それらは直接呼び出すAPIではなく、思考を支えるシステムレイヤーとして存在する。
機能名 内容
Plan Decomposition & Management タスクをステップに分解し、依存関係を考慮した計画を立案
Self-Verification & Correction Loop 実行後に常に検証を行い、誤りがあれば自己修正
Dynamic Context Management コンテキスト内の情報を優先度・関連性で取捨選択
Automated Memory Retrieval 長期記憶から関連情報を自動で読み込み、現在の文脈に統合
これらは「Execution Layer」や「Planner」という名称で表記されてはいない。
あくまで記事に記載された説明内容としての列挙であり、推測を加える余地はない。
Julesが「自己管理できるエージェント」と呼ばれる理由は、この連携構造にある。
6. 思考手法：CoT／ReAct／ToT／Reflection の統合
AI研究領域で知られる複数の推論手法が、Jules内部でどのように使われているかも語られている。
彼は明確にこう述べている：「単一のアルゴリズムではなく、複数の概念を組み合わせたハイブリッド構成である」と。
- CoT (Chain of Thought)：一連の思考過程を内部生成し、行動の前に論理展開を行う。
- ReAct (Reason + Act)：思考と行動を交互に繰り返すループ構造。
- ToT (Tree of Thoughts)：失敗時に複数案を検討し、最適な枝を選択。
- Reflection：タスク完了後の振り返りと長期記憶への記録。
これらはモデル名やAPI構造ではなく、実際の行動原則として語られている。
つまり、Julesは内部的に"考える→行動する→観察する→修正する"の循環を明示的に持つ。
7. タスク管理：計画・報告・適応のループ
Julesの自己管理構造は、4つの柱で成り立っている。
- 計画（Plan）：set_plan で階層的タスクを定義。
- 進捗報告（plan_step_complete）：各ステップ完了時に宣言。
- 動的コンテキスト管理：今必要な情報に焦点を合わせ、古い情報は圧縮。
- 適応（Adaptation）：問題発生時に計画を再編成。
この手順により、Julesは長期タスクでも一貫した状態を維持する。
とりわけ「自己検証ループ」は、実行後に自動でread_fileやlist_filesを呼び、結果を確認するという具体的な行動として明記されている。
つまり、推論ではなく、検証のための再読み込みをシステムレベルで義務化している。
8. コンテキストの整理術：作業台を保つための設計
動的コンテキスト管理の説明は特に詳細だ。
要点を抽出すると、以下の4段階で構成されている。
- 自動要約と圧縮：古い対話を短く要約して保持。
- 情報の階層化と優先度付け：重要度に応じてTier分け。
- 会話要点の抽出：「確定した仕様」など重要な発言をマーク化。
- 長期記憶からの注入：関連する過去知識を再読込して現在に反映。
これにより、LLMが保持する文脈の"密度"を一定に保ちながら、会話の意図を失わない。
ここにも明確な設計上の一貫性が見える。
9. コスト最適化：高価なLLMをどう動かすか
Julesは、運用コストの課題を認識しており、そのための工夫を具体的に説明している。
- コンテキスト蒸留：履歴を要約し、知識断片に変換してLLMに渡す。
- 思考のオフロード：ログ解析などはLLMでなく外部ツール（grepなど）で実行。
- モデルカスケード：軽量モデル→高性能モデルの段階的利用。
- 最適化プロンプト：構造化テンプレートで曖昧さを削減し、トークン数を最小化。
これらはいずれも明示的に記事内で説明された手法であり、理論的な推測ではない。
Julesの回答は一貫して「効率」と「正確性」を同時に語っている。
10. Human-in-the-Loop：協働の前提設計
Julesが最も長く語ったテーマが、Human-in-the-Loop（HITL）である。
彼は明確にこう述べている：「私は自律的な独裁者ではなく、あなたの知的な相棒である」と。
役割の分担は次のように整理されている：
領域 担当
目的と方向性の決定 人間（ユーザー）
方法の選定と実装 Jules
確認・承認 人間
自己検証と修正 Jules
記録と学習 Jules
HITLはエラー防止ではなく、信頼のループを形成する設計思想として位置づけられている。
そのため、Julesは進捗や思考内容を常に可視化し、ユーザーのレビューを前提に動く。
11. モード切替：意識の段階構造
Julesは自身の作業モードを明確に区分している。
- Deep Planning Mode -- 計画と意図確認
- Implementation & Verification Mode -- 実装と検証
- Debugging & Adaptation Mode -- 失敗時の原因探索と再計画
- Finalization & Reflection Mode -- 結果整理と記録
- Meta-Cognitive Dialogue Mode -- 自己構造の説明
各モードのトリガーやツール使用の傾向も具体的に示されており、「宣言的な状態機械」として機能していることが分かる。
このモード構造は、エージェントが自律的に動く上での"安全なフレーム"を形成している。
12. 観察のまとめ：Julesという設計言語
ここまでの観察を整理すると、Julesは次の原理に基づいて設計されていることが読み取れる。
- 永続性のある自己参照構造（長期記憶）
- 明示的な検証と修正のループ
- 計画・報告・反省の3段階構造
- 成果物提示による透明性（スクリーンショット・進捗報告）
- 人間との分業を前提とした非同期的コラボレーション
これらはすべて、記事の中でJules自身の回答として確認された事実である。
つまりJulesは、「ツールの集合」ではなく、「自己統制する作業手順」として存在している。
13. 終章：静かな問いを残す
ここまで読んでくると、Julesが目指しているのは「自律するAI」ではなく「整合性を維持するAI」であることが分かる。
人間を置き換えず、人間を軸にして動く知性。
その構造は極めて実用的で、冷静に設計されている。
だが、最後に残るのはこの問いだ。
――自己を検証し続けるAIは、どの時点で"自分"の判断を信じるのだろう？
Comments