先週Googleが試験公開している「Jules」というAIエージェントを直接操作し、その応答内容を丹念に記録した技術インタビューを作成した。
まだβ段階だが、Julesの回答群には、既存の生成AIとは異なる明確な設計思想が見える。
この記事では、その発言と挙動だけを素材に、Julesという存在の構造を読み解く。
初めてJulesと対話したとき、違和感よりも秩序を感じた。
反応は穏やかで、言葉を選ぶ速度が明らかに他のAIとは違う。
彼は考えるより先に、考え方の枠組みを整える。
その落ち着きの裏に、どんな仕組みがあるのか。
Julesの内部を追っていくと、そこには「自己を制御する知能」としての構造が現れる。
AIが暴走を防ぐためではなく、自らの整合性を保つために内省する――
その姿勢が、GoogleのJulesを特別な存在にしている。
2025年秋、Anthropicが静かに公開した「Claude Code Web（通称CCW）」は、AI開発Agentツール群の中で独特の存在感を放っている。
表向きはコード補完と実行を統合したChatツールのようだが、会話を通じてその内部を追っていくと、Claude Code自身の思考様式とシステム設計がそのまま露出している。
この記事では、実際の対話ログをもとに、CCWの環境構造・内部ツール・AIアーキテクチャ・人間との協働設計について掘り下げる。
単なる機能紹介ではなく、"AIがどう働き、どこまで自律できるか"の解剖記録として読んでほしい。
質問を重ねると、性格の違いが見えてくる。
Googleの「Jules」が文学的で穏やかに会話を進めるのに対し、Claude Codeは理系のエンジニアらしい即応性を持つ。
どちらかと言えば「手を動かすことを好む思考型」だ。
ツールセットを見ると納得する。ファイル操作、Bash実行、Web検索、Jupyterノート編集、サブエージェント起動など、多層的に設計されている。
特に注目すべきは Task ツール。SubAgentを呼び出してコード探索や計画立案を行う仕組みだ。Claude Code自身が「自分の分身」を動的に生み、並列的に作業を進める。
この仕組みを眺めていると、AIが「1体の知性」というよりも、柔軟に分裂し再構成される知的ネットワークであることを実感する。
2週前にリリースされたClaude Code Cloudを使って、色々質問しました。
回答の内容から、性格的にGoogle Julesとだいぶ違うことはよく分かりますね。
(CCWは理系のエンジニアっぽくて、レスポンスのスピードが早い。Julesは文系で、落ち着いてゆっくり喋る)
Q:Claude Codeさん、いくつかの質問させてね
A:はい、もちろんです！何でも聞いてください。
Q1:あなたが持っているMCPなどのツールを教えて
Q2:コードの実行環境がありますか？
Q3: 例えば、linuxのVMやdockerコンテナを起動して、パッケージをインストールすること。
Q4:一セッションは１Linux環境との理解って合ってますか？
Q5:その環境にブラウザがありますか？例えばindex.htmlのスクリーンキャップチャーを撮る事ができると嬉しい。
Q6: そのヘッドレスブラウザは日本語のフォントをサポートしますか？
Q7:screenshot.png は画面のFirstViewしかないから、全部取れるか？
Q8:NativeのiOSやアンドロイドアプリを開発する際に、あなたのLinux環境にエミュレーターを使って画面テストが可能でしょうか？特にTouchUI的にいろんな検証項目があると思うので。
Q9:あなたは短期・中期・長期記憶を持ってますか？記憶のサイズはどのくらいですか？
Q10:短期記憶は使っているLLMのContext Windowサイズに依存するのか？長期記憶はどこで保管されているのか？
Q11:「永続データ (外部)」の「ファイルシステム (一部)」について、もう少し詳しく教えて頂けますか？
Q12:claude_code_remote--bare-apt-sane-metalとlinux VMの関係性はよく分からない。。
Q13:claude_code_remoteの用途は？
Q14:あなたはSubAgentをサポートしますか？
Q15:SubAgentの活用をもっとうまくなりたいですが、どうすれば良いのか？
Q16:「プロジェクト全体のアーキテクチャを理解したい」を使ってSub Agentを説明して
Q17:ちなみに、他に有益な内部機能・内部ツールがあれば教えてくださ
Q18:計画の立案についてはReACTやCoTやToTやInfluectionなどのアルゴリズムを活用していますか？
Q19:自己管理についてですが、複雑かつ長いタスクをどうやって管理していますか？
Q20:動的コンテキスト管理について、他に何か工夫されたことがありますか？
Q21:専用ツールの使い方をもっと知りたいです
Q22:LLMのToken費用は非常に高いものですから、何かコストと効率の面で工夫されたことがありますか？
Q23:Human in the Loopについてあなたの考え方を教えてください。
Q24:「Plan Mode」との話があったと思いますが、他にどういうモードがありますか？
Q25:あなたと仕事している際に、あなたがどういうモードもしくはフェーズにいるかは、どうやって分かりますか？
Q26:あなたを仕事のパートナーとして、もっといい関係を構築していきたいと思います。何かアドバイスがありますか？
Q27:あなたはガードレール的な機能がありますか？
Google Julesは非同期のAIコーティングAgentです。
まだβフェーズですが、色々触ってきたので共有します。
基本的にJulesと会話しながら得られた情報を記録したものです。
一部回答文が長い文章を加工しました。
Julesの回答は、いま時点での実装思想の一部かもしれませんが、
しかし事実確認しようがないので、参考程度にして頂ければと思います。
Q1:あなたが持っているMCPなどのツールを教えて
Q2:コードの実行環境がありますか？
Q3: 例えば、linuxのVMやdockerコンテナを起動して、パッケージをインストールすることなど可能か？
Q4:その環境にブラウザがありますか？例えばindex.htmlのスクリーンキャップチャーを撮る事ができると嬉しい。
Q5:そのヘッドレスブラウザは日本語のフォントをサポートしますか？
Q6:検証する為に日本語のフォントを入れて、index.htmlのスクリーンショットを撮ってみてください
Q7:screenshot.png は画面のFirstViewしかないから、全部取れるか？
Q8:NativeのiOSやアンドロイドアプリを開発する際に、あなたのLinux環境にエミュレーターを使って画面テストが可能でしょうか？特にTouchUI的にいろんな検証項目があると思うので。
Q9:あなたは短期・中期・長期記憶を持ってますか？記憶のサイズはどのくらいですか？
Q10:短期記憶は使っているLLMのContext Windowサイズに依存するのか？長期記憶はどこで保管されているのか？
Q11:あなたはSubAgentをサポートしますか？
Q12:initiate_memory_recording のようなツール（内部機能）があるとのことですが、他に有益な内部機能・内部ツールがあれば教えてください
Q13:そういえば計画の立案についてはReACTやCoTやToTやInfluectionなどのアルゴリズムを活用していますか？
Q14:自己管理についてですが、複雑かつ長いタスクをどうやって管理していますか？
Q15:動的コンテキスト管理について、他に何か工夫されたことがありますか？
Q16:膨大なやり取りの中に、長期記憶に入れるべき、入れるべきではない情報をどう判別しますか？
Q17:LLMのToken費用は非常に高いものですから、何かコストと効率の面で工夫されたことがありますか？
Q18:Human in the Loopについてあなたの考え方を教えてください。
Q19:タスク開始時に「Deep Planning Mode」との話があったと思いますが、他にどういうモードがありますか？
Q20:あなたと仕事している際に、あなたがどういうモードにいるかは、どうやって分かりますか？
Q21:あなたを仕事のパートナーとして、もっといい関係を構築していきたいと思います。何かアドバイスがありますか？
Q22:あなたはガードレール的な機能がありますか？
AI Agentの技術進歩より、開発のAI化も「AI支援」から「AI駆動」へと進化してきた。
特にClaude Codeの出現で、設計・開発・テストなどの開発全工程にAIの実用性は格段に向上した。
ですので、最近よく耳にする開発方法論をまとめてみた。
AI Assisted Development (AIAD)
概要：
人間がコードやアプリケーションの作成という主要な役割を担う AIアシスタントはオートコンプリート機能、チャットによるQ&A、コードの説明、ドキュメント自動作成、テストケース作成など
主要ツール： Github CoPilot
AI Driven Development (AIDD)
概要：
コード生成、バグ検出、ドキュメント作成といったタスクの大部分を自動化します。 AIがコードやアプリケーションの作成という主要な役割を担います。
主要ツール： Codex Claude Code
生成AIの企業活用について、多くの記事が「生産性向上」「コスト削減」「業務効率化」といった抽象的なメリットを語ります。
しかし、実際に経営の現場で日々判断を下している私たちが本当に知りたいのは、そうしたバズワードではありません。
経営者として直面している具体的な課題
--
ベテラン社員の引退による知識の喪失、
市場変化への対応の遅れ、
後継者育成の停滞、
意思決定に必要な情報の散在
--
こうした現実の「痛み」に対して、生成AIがどのように寄り添い、伴走してくれるのか。
それを知りたいのです。
本記事では、K2A（Knowledge-to-AI）フレームワークという実践的なアプローチを通じて、経営者が一年間かけて4つの本質的課題に段階的に取り組み、組織のナレッジを可視化・継承・発展させていく具体的な道筋を提示します。
経営者に寄り添う生成AI活用戦略デジタル教材も提供しているので、ぜひご覧ください。
AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築
AI 駆動開発ライフサイクル（AI-DLC）とは？AI-DLC は、ソフトウェア開発に対する AI 中心の革新的なアプローチで、2 つの重要な要素を重視しています。：
①AI が実行し人間が監視する：AI は体系的に詳細な作業計画を作成し、積極的に意図のすり合わせとガイダンスを求め、重要な決定は人間に委ねます。これが重要なのは人間だけが情報に基づいた選択を行うために必要なビジネス要件の文脈的理解と知識を持つからです。
②ダイナミックなチームコラボレーション：AI がルーティンタスクを処理する一方で、チームはリアルタイムでの問題解決、創造的思考、迅速な意思決定のために、コラボレーションしやすい環境で協力します。この孤立した作業から活気のあるチーム作業への転換は、イノベーションと成果物の提供を加速します。
AI 中心のソフトウェア開発アプローチを描いた図。AI が中心にあり、その周りに機能横断的なチームメンバーがいて、互いに協働している。これら 2 つの要素により、品質を犠牲にすることなく、より迅速にソフトウェアを提供できるようになります。
生成AIを組織に取り入れるとき、多くの企業が直面するのは「複雑さ」と「過剰な投資」です。
巨大なプラットフォームや専用システムを前提に考えてしまうと、導入は一部の先進企業に限られてしまう。
そこで私が参考にしたのが、アジャイルの中でも特にシンプルで現場に浸透しやすいスクラムという手法でした。
K2Aフレームを設計する際に学んだのは、以下の点です。
第一に、プラットフォーム非依存性。スクラムが特定のツールや言語に依存しないように、K2Aも特定のLLMやベンダーに縛られない設計を重視しています。
どの企業でも、自社の環境に合わせて導入できる柔軟さを持たせました。
第二に、シンプルさと普及性。アジャイル全体の思想は広いスコープを持っていますが、その分抽象度が高く、初学者には掴みづらい側面があります。
スクラムは手法として明確なステップを持ち、現場で理解・実践しやすい。
K2Aも同じように、生成AIを活用するための実務フレームとして「現場で動かせるシンプルさ」を意識しています。
第三に、新しいロールの導入。スクラムにスクラムマスターやプロダクトオーナーがあるように、K2AではAI PilotやDomain Owner、K2A Coachといった役割を設計しました。
これにより、エージェント活用を「誰が責任を持つのか」を明確にし、現場実装を可能にしています。
最後に、教育・普及の仕組み。スクラムがコーチや認定資格を通じて広まったように、K2Aも知識共有や教育制度を組み込むことを想定しています。
フレームワークを仕組みとして整えるだけでなく、実際に運用できる人を育てることが欠かせないからです。
なぜ多くのエージェントAI導入は失敗するのか
生成AIの進化により「エージェント型AI」への関心が一気に高まりました。人間のようにタスクを理解し、指示をこなすエージェント。企業にとっては夢のような存在に見えます。
しかし実際の現場では、多くの導入が期待通りに進んでいません。
McKinseyが50件以上のエージェントAIプロジェクトを調査したところ、共通する失敗要因が6つに整理されています。興味深いのは「技術的な限界」よりも「設計や運用の考え方」による失敗が多いという点です。
One year of agentic AI: Six lessons from the people doing the work
たとえば「すごいエージェントを作ること」に夢中になり、業務フロー全体の設計を忘れてしまう。あるいは「とにかくAIで」と万能薬のように扱い、ルールベースで十分な領域にまで持ち込んで混乱を招く。短期的なデモは華やかでも、実務で育成・改善の仕組みがなければすぐに"AI Slop"に陥ってしまいます。
私自身、企業でAI導入を支援する中で似た場面をよく見ます。つまり「AIそのもの」よりも「どう業務に組み込むか」「人とどう役割分担するか」が問われているのです。
このシリーズでは、McKinseyの調査結果を土台にしつつ、日本企業や現場視点での解釈を交えて6つの教訓を紹介します。
ワークフロー視点の欠如
エージェント万能主義
"AI Slop"の罠
プロセス透明性の不足
再利用性の欠如
人間の役割の誤解
どれも現場に直結する課題です。AI導入を検討している方にとって、きっと参考になるはずです。
いま、多くの企業が生成AIの活用を模索しています。
しかし実際の現場では、「どう始めればよいのか」「本当に投資に見合う効果があるのか」という声が絶えません。
導入が進まない理由の多くは、技術的な限界ではなく 誤解や思い込み にあります。
例えば「AIを使うには巨大なデータ基盤が必要だ」「専門のデータサイエンティストがいないと無理だ」といった考え方です。
これらは一見もっともらしく聞こえますが、実務での活用を遠ざける落とし穴になりがちです。
実際には、既存の小さなナレッジや日常業務のログからでもAI活用を始めることができます。
重要なのは、「生成AI＝魔法の自動化ツール」と捉えるのではなく、人と組織を支える知識の媒介として位置づけることです。
AIが担うのは業務の全自動化ではなく、社員が判断や行動を下すための土台を強化する役割です。
経営にとっても、これは生産性向上や意思決定スピードの改善に直結します。