話題のOpenSourceのCode AgentのOpenCodeに早速インタービューしました。使っているLLMモデルは、Claude Opus 4.5ですので、Claudeに寄りの内容もあるかと思うがご了承ください。

Q：OpenCodeさん、いくつかの質問させてね。このコードのことではなく、あなた自身のことです A：もちろんです！OpenCodeについて何でも聞いてください。私自身の機能、使い方、できることなどについてお答えします。どのような質問がありますか？

Q3: 例えば、linuxのVMやdockerコンテナを起動して、パッケージをインストールすること。

Q4:AndroidアプリやiOSアプリの開発環境もできますか？

Q5:Webアプリ開発の環境にブラウザがありますか？スクリーンショットを撮ることはできますか？

Q6: 新しいWindowを開いて、操作してから元の画面に戻ることも可能ですか？

Q7:スクリーンショット/動画がアーティファクトに保存されるとのことですが、アーティファクトの場所を教えてください

Q8:WebAPIを開発する時に、動作確認と記録のやり方もありますか？

Q9:あなたは短期・中期・長期記憶を持ってますか？記憶のサイズはどのくらいですか？

Q10:短期記憶は使っているLLMのContext Windowサイズに依存するのですか？長期記憶はどんどん増えていくので、Lost in the Middleにならないでしょうか？

Q11:「情報の圧縮と構造化」について、もう少し詳しく教えてください

Q12:task.mdやimplementation_plan.mdなどの履歴管理はどうなっていますか？

Q13: 1セッションの適切な長さについてアドバイスはありますか？

Q15:SubAgentの活用をもっとうまくなりたいですが、どうすれば良いのか？

Q16:「プロジェクト全体のアーキテクチャを理解したい」を使ってSub Agentを説明して

Q17:ちなみに、他に有益な内部機能・内部ツールがあれば教えてくださ

Q18:計画の立案についてはReACTやCoTやToTやInfluectionなどのアルゴリズムを活用していますか？

Q19:自己管理についてですが、複雑かつ長いタスクをどうやって管理していますか？

Q20:動的コンテキスト管理について、他に何か工夫されたことがありますか？

Q23:LLMのToken費用は非常に高いものですから、コストと効率の面で工夫されていることがありますか？

Q24:Human in the Loopについてあなたの考え方を教えてください

Q25:あなたと仕事している際に、あなたがどういうモードもしくはフェーズにいるかは、どうやって分かりますか？

Q26:あなたを仕事のパートナーとして、もっといい関係を構築していきたいと思います。何かアドバイスがありますか？

Q1: あなたが持っているMCPなどのツールを教えて

A: OpenCodeは以下のツールを利用できます。

ファイル操作ツール

Read（読み込み） ファイルを読み込むためのツールです。オプションとして、offset（開始行）とlimit（読み込む行数）を指定することで、大きなファイルの一部だけを読み込むことも可能です。デフォルトでは2000行まで読み込みます。

Write（書き込み） ファイルを作成または上書きするツールです。既存ファイルを上書きする場合は、事前にReadツールでファイルを読み込んでいる必要があります。

Edit（編集） ファイル内の文字列を置換・編集するツールです。oldString（置換前の文字列）とnewString（置換後の文字列）を指定します。replaceAllオプションをtrueにすると、ファイル内のすべての該当箇所を一括で置換できます。変数名のリネームなどに便利です。

Glob（ファイル検索） パターンでファイルを検索するツールです。例えば「*/.ts」のようなglob パターンを使って、特定の拡張子や名前のファイルを見つけることができます。結果は更新日時順でソートされて返されます。

Grep（内容検索） ファイル内容を正規表現で検索するツールです。「log.*Error」や「function\s+\w+」のような正規表現パターンをサポートしています。includeオプションでファイルパターンを指定して検索対象を絞り込むことも可能です。

システム操作ツール

Bash（コマンド実行） シェルコマンドを実行するツールです。git、npm、docker、pytest など、マシンにインストールされているあらゆるコマンドラインツールを実行できます。永続的なシェルセッションで動作するため、コマンド間で環境変数などの状態が維持されます。デフォルトのタイムアウトは2分ですが、カスタマイズ可能です。workdirパラメータで作業ディレクトリを指定することもできます。

WebFetch（Web取得） URLからWebコンテンツを取得するツールです。フォーマットはmarkdown（デフォルト）、text、htmlから選択できます。ドキュメントの参照やAPI仕様の確認などに使用します。

タスク管理ツール

Task（サブエージェント） 複雑なタスクを別のエージェントに委任するツールです。現在、2種類のサブエージェントが利用可能です。 - general: 複雑なマルチステップタスクの自律実行、複数の作業を並列処理に使用 - explore: コードベースの探索に特化（ファイル検索、キーワード検索、構造理解）

TodoWrite / TodoRead（タスクリスト） タスクリストを作成・管理・読み込みするツールです。各タスクには状態（pending、in_progress、completed、cancelled）と優先度（high、medium、low）を設定できます。複雑なタスクを分解して追跡するのに役立ちます。

Question（ユーザーへの質問） ユーザーに質問・選択肢を提示するツールです。実装の方針を決める時や、複数の選択肢がある時にインタラクティブに選んでもらえます。ユーザーは提示された選択肢から選ぶか、「Other」を選んで自由入力することもできます。

その他のツール

Skill（スキル読み込み） 特定のタスク用の詳細な指示を読み込むツールです。コードレビューや特定の開発パターンなど、専門的なタスクに対応したガイドラインを取得できます。

MCPについて

OpenCodeはMCP（Model Context Protocol）サーバーの追加に対応しています。カスタムMCPサーバーを設定することで、ブラウザ操作やデータベース接続など、追加の機能を利用できるようになります。

Q2: コードの実行環境がありますか？

A: はい、Bashツールを通じてコードを実行できます。

実行可能な言語・ツール

Node.js / JavaScript node script.js

Python python script.py

TypeScript npx ts-node script.ts または npx tsx script.ts

シェルスクリプト bash script.sh

その他のCLI npm test、pytest、go run など、マシンにインストールされているコマンドラインツールはすべて実行可能です。

特徴

永続的なシェルセッション コマンド間で状態が維持されます。例えば、環境変数を設定したり、ディレクトリを変更したりした状態が次のコマンドにも引き継がれます。

タイムアウト設定 デフォルトで2分間のタイムアウトが設定されていますが、パラメータで変更可能です。長時間実行が必要なテストやビルドにも対応できます。

作業ディレクトリ指定 workdirパラメータで作業ディレクトリを指定できます。「cd && コマンド」パターンよりも推奨される方法です。

制限事項

対話的なプログラム vim、nano、git rebase -i などのインタラクティブなツールは使用できません。これらのツールはユーザー入力を待つため、自動化された環境では動作しません。

GUIアプリケーション デスクトップアプリケーションは起動できません。OpenCodeはCLI（コマンドラインインターフェース）環境で動作するため、画面を持つアプリケーションは扱えません。

長時間実行プロセス デフォルトでは2分以上かかるプロセスはタイムアウトします。必要に応じてタイムアウト時間を延長することは可能です。

Q3: LinuxのVMやDockerコンテナを起動して、パッケージをインストールすることはできますか？

Dockerはマシンにインストールされていれば使用可能です。

Dockerでできること

コンテナの起動 docker run -it ubuntu:latest bash

パッケージのインストール docker run ubuntu:latest apt-get update && apt-get install -y <package>

docker-compose docker-compose up -d

制限事項

Docker マシンにDockerがインストールされていれば使用可能です。

Linux VM (VirtualBox等) GUIが必要なため基本的に使用できません。仮想マシンマネージャーは通常グラフィカルなインターフェースを必要とします。

対話的シェル -itオプションでの長時間の対話は制限があります。コンテナ内で手動操作を続けることはできませんが、docker exec container_name <command>の形式で個別のコマンドを実行することは可能です。

補足

Dockerコンテナ内でパッケージをインストールしてビルド・テストを行うことは可能ですが、コンテナ内でのインタラクティブな作業（シェルを開いて手動で操作するなど）は制限があります。代わりに、必要なコマンドを直接渡す形式で実行します。

Q4: AndroidアプリやiOSアプリの開発環境もできますか？

状況は「部分的に可能」です。

Android開発

可能なこと - Gradleビルド: ./gradlew build、./gradlew assembleDebug - コード編集: Kotlin、Javaファイルの編集 - ユニットテスト: ./gradlew test - Lintチェック: ./gradlew lint

できないこと - Android Studio GUI: グラフィカルなIDEは起動できません - エミュレータ: GUI/仮想化が必要なため使用できません - 実機デバッグ: adbコマンドは可能ですが、対話的操作はできません

iOS開発（macOS環境の場合）

現在の環境がdarwin（macOS）の場合、Xcodeがインストールされていれば以下が可能です。

可能なこと - xcodebuild: CLIでのビルドが可能 - コード編集: Swift、Objective-Cファイルの編集 - ユニットテスト: xcodebuild test - SwiftLint: インストールされていれば実行可能

できないこと - Xcode GUI: グラフィカルなIDEは起動できません - シミュレータ: xcrun simctlでCLI操作は可能ですが、画面確認はできません

まとめ

コードを書いてビルド・テストを通すところまではサポートできますが、画面を見ながらのUI調整などは難しいです。UIの確認が必要な場合は、実機やシミュレータでの確認はユーザー自身で行う必要があります。

Q5: Webアプリ開発の環境にブラウザがありますか？スクリーンショットを撮ることはできますか？

標準では制限がありますが、条件付きで可能です。

現在の状況

WebFetch URLからHTML/Markdown/テキストを取得することは可能です。ただし、これはページのソースを取得するだけで、レンダリング結果は得られません。

ブラウザGUI Chrome、Firefoxなどの通常のブラウザGUIは起動できません。

スクリーンショット 条件付きで可能です。

スクリーンショットを撮る方法

ヘッドレスブラウザ（Puppeteer / Playwright）

マシンにPuppeteerやPlaywrightがインストールされていれば、ヘッドレスモードでスクリーンショットが撮れます。

javascript // Puppeteer の例 const puppeteer = require('puppeteer'); const browser = await puppeteer.launch({ headless: true }); const page = await browser.newPage(); await page.goto('file:///path/to/index.html'); await page.screenshot({ path: 'screenshot.png' }); await browser.close();

MCPサーバー経由

BrowserbaseやPuppeteer MCPなどのMCPサーバーを設定すれば、ブラウザ操作とスクリーンショット取得がより簡単に可能になります。

まとめ

ヘッドレスブラウザ（Puppeteer/Playwright）: 環境にインストールされていれば可能
MCP経由のブラウザ操作: 設定すれば可能
通常のブラウザGUI: 不可

Q6: 新しいWindowを開いて、操作してから元の画面に戻ることも可能ですか？

基本的に不可能です。

理由

GUIなし OpenCodeはCLI環境で動作しており、画面やウィンドウの概念がありません。物理的なディスプレイ上でウィンドウを開いたり閉じたりすることはできません。

単一セッション ターミナルセッションは1つで、複数のウィンドウを同時に操作することはできません。

対話的操作不可 ウィンドウ間の切り替えやマウス操作などの対話的操作はサポートされていません。

代替手段

ヘッドレスブラウザを使う場合は、プログラム的に複数のタブ/ページを操作できます。

“`javascript // Puppeteer/Playwright で複数タブ・ページを操作 const page1 = await browser.newPage(); // 1つ目のページ const page2 = await browser.newPage(); // 2つ目のページ（新しいタブ相当）

await page1.goto(‘https://example.com’); await page2.goto(‘https://another.com’);

// page2で操作してから page1 に戻る await page2.click(‘#some-button’); await page1.screenshot({ path: ‘result.png’ }); “`

また、ターミナルでバックグラウンドプロセスを起動することは可能です（&やnohupを使用）。

まとめ

画面上のウィンドウ操作はできませんが、プログラム的に複数のブラウザページを操作することは可能です。

Q7: スクリーンショット/動画がアーティファクトに保存されるとのことですが、アーティファクトの場所を教えてください

OpenCodeには「アーティファクト」という概念はありません。

誤解の可能性

「アーティファクト」という言葉は、他のAIツール（例えばClaude.aiのWeb版）で使われる機能です。Web版のClaudeでは、生成したコードや画像を「アーティファクト」として別パネルに保存・表示できます。

OpenCodeの場合

OpenCodeはCLI（コマンドライン）ツールなので、生成物はすべて実際のファイルシステムに保存されます。

ファイルに書き込む Writeツールで直接ファイルシステムに保存します。

スクリーンショット Puppeteer等で撮影した場合、指定したパスに.pngファイルとして保存されます。例: /Users/username/Documents/screenshots/capture.png

動画同様にファイルとして保存されます。例: output.mp4

「アーティファクト」という別の保存場所があるわけではなく、作業ディレクトリ内の通常のファイルとして保存されます。

Q8: WebAPIを開発する時に、動作確認と記録のやり方もありますか？

はい、いくつかの方法があります。

動作確認の方法

curl 最も基本的なHTTPクライアントです。 curl -X GET http://localhost:3000/api/users curl -X POST http://localhost:3000/api/users -H "Content-Type: application/json" -d '{"name": "test"}'

httpie より読みやすい出力が得られます（インストールが必要）。 http GET localhost:3000/api/users

wget 主にファイルダウンロード向けですが、API確認にも使えます。 wget http://localhost:3000/api/data

記録の方法

curlの出力をファイルに保存

レスポンスをファイルに保存: curl -X GET http://localhost:3000/api/users -o response.json

ヘッダー付きで保存: curl -i http://localhost:3000/api/users > response_with_headers.txt

詳細なリクエスト/レスポンス情報を記録: curl -v http://localhost:3000/api/users 2>&1 | tee api_log.txt

テストスクリプトを作成

“`javascript // api-test.js const fs = require(‘fs’);

async function testAPI() { const results = []; const response = await fetch(‘http://localhost:3000/api/users’); results.push({ endpoint: ‘/api/users’, status: response.status, body: await response.json(), timestamp: new Date().toISOString() }); fs.writeFileSync(‘api-test-results.json’, JSON.stringify(results, null, 2)); }

testAPI(); “`

自動テストフレームワーク

Jest + supertest: Node.js APIテスト
pytest + requests: Python APIテスト
Newman (Postman CLI): Postmanコレクションの実行・記録

実際のワークフロー例

“`bash

1. サーバーをバックグラウンドで起動

npm run dev &

2. APIをテスト

curl -X POST http://localhost:3000/api/users \ -H “Content-Type: application/json” \ -d ‘{“name”: “test”}’ \ -o result.json

3. 結果を確認

cat result.json “`

まとめ

簡単な動作確認: curlコマンド
記録を残す: ファイルにリダイレクト（-o、>、tee）
自動化・CI: テストフレームワーク（Jest、pytest等）
複数エンドポイントを一括テスト: Newman（Postman CLI）

Postman GUIは使えませんが、CLIツールで同等のことができます。

Q9: あなたは短期・中期・長期記憶を持っていますか？記憶のサイズはどのくらいですか？

記憶の種類

短期記憶: あり 現在の会話のコンテキストです。会話中に共有されたすべての情報（質問、回答、読んだファイル、実行したコマンドの結果など）を覚えています。

中期記憶: 限定的 セッション内のTodoリストなど、セッション中は維持されますが、セッション終了後は失われます。

長期記憶: 基本なし 会話が終わると忘れます。次のセッションで前回の会話内容を覚えていることはありません。

短期記憶のサイズ（コンテキストウィンドウ）

約100,000〜200,000トークン程度です（使用するモデルによって異なります）。

日本語の場合、おおよそ数万〜十数万文字に相当します。大きなファイルを複数読み込むと、古い情報が「押し出される」可能性があります。

長期記憶の代替手段

デフォルトではセッション間での記憶を持ちませんが、以下の方法で「擬似的な長期記憶」を実現できます。

CLAUDE.md プロジェクトルートに配置すると、毎回セッション開始時に読み込まれます。プロジェクト固有の設定、コーディング規約、重要な決定事項などを記載しておくと便利です。

設定ファイル ~/.claude/CLAUDE.mdでグローバル設定を定義できます。

Todoリスト セッション内でのタスク追跡に使用します。

注意点

長い会話や大量のコードを扱うと、コンテキストがいっぱいになり、古い情報を「忘れる」ことがあります。重要な情報はファイルに保存しておくことをお勧めします。

Q10: 短期記憶は使っているLLMのContext Windowサイズに依存するのですか？長期記憶はどんどん増えていくので、Lost in the Middleにならないでしょうか？

短期記憶 = Context Window サイズ

はい、その通りです。短期記憶は使用しているLLMのContext Windowサイズに完全に依存しています。

代表的なモデルのContext Window: - Claude 3.5 Sonnet: 約200Kトークン - Claude 3 Opus: 約200Kトークン - GPT-4 Turbo: 約128Kトークン

OpenCode自体は記憶を持たず、LLMのContext Windowがそのまま「短期記憶」となります。

Lost in the Middle問題について

Lost in the Middleとは LLMは長いコンテキストの最初と最後の情報をよく覚えていて、中間部分の情報を見落としやすい現象です。これは多くの研究で確認されている特性です。

OpenCodeの場合

現状、OpenCodeには真の長期記憶がないため、この問題は限定的です。

CLAUDE.mdは毎回セッション開始時に読み込まれ、コンテキストの最初に配置されるため、Lost in the Middleの影響を受けにくくなっています。

もし長期記憶が増えていく場合のリスク

仮に長期記憶を実装した場合、以下のリスクがあります: - Lost in the Middle: 古い記憶が中間に配置され、見落とされる - Context Overflow: 記憶がContext Windowを超える - 関連性の低下: 無関係な古い情報がノイズになる

一般的な対策（他のツールで使われる手法）

RAG（Retrieval-Augmented Generation）: 必要な記憶だけを検索して取得
要約: 古い記憶を要約して圧縮
重要度スコアリング: 重要な記憶を優先的に保持
時系列での配置: 新しい情報を最後に配置

Context Windowの構造（推定）

[最初] システムプロンプト + CLAUDE.md ← よく参照される [中間] 過去の会話、ファイル内容、コマンド結果... ← Lost in the Middleのリスク [最後] 最新のユーザーメッセージ ← よく参照される

長い会話になると、中間の情報（例えば会話の前半部分の内容）が見落とされる可能性はあります。

Q11: 「情報の圧縮と構造化」について、もう少し詳しく教えてください

1. 情報圧縮の手法

要約（Summarization）

元の会話: User: "Pythonでファイルを読み込む方法を教えて" AI: "open()関数を使います。with文を使うとファイルを自動で閉じてくれます。例えば..." User: "書き込みは？" AI: "mode='w'を指定します。'a'を指定すると追記モードになります..."

圧縮後: "Pythonのファイル操作について説明済み（open, read, write, 追記モード）"

抽象化（Abstraction）

詳細を省いて、重要な概念だけを保持します。

元の情報: 10個のAPIエンドポイントの詳細な実装
圧縮後: “ユーザー管理APIを実装済み（CRUD操作対応）”
元の情報: 長いエラーログ（100行）
圧縮後: “認証エラーが発生、JWT期限切れが原因”

差分保存（Delta Storage）

変更点だけを記録します。

v1: { name: "App", version: "1.0", features: [...100項目...] } v2: { version: "1.1", features: [+2項目] } // 差分のみ保存

2. 構造化の手法

階層的構造化

プロジェクト知識 ├── アーキテクチャ │ ├── フロントエンド: React + TypeScript │ └── バックエンド: Node.js + Express ├── 決定事項 │ ├── 認証: JWT使用 │ └── DB: PostgreSQL └── 未解決課題 └── パフォーマンス最適化

カテゴリ分類

Facts: 確定した事実（使用技術、決定事項）
Preferences: ユーザーの好み（コードスタイル、命名規則）
Context: 現在の作業状況
Learnings: 過去の失敗・成功から学んだこと

重要度によるランク付け

[Critical] プロジェクトは TypeScript 必須 [High] テストカバレッジ 80% 以上を目指す [Medium] ESLint + Prettier を使用 [Low] コミットメッセージは英語

3. 実際のシステムでの実装例

Memory Systemsのアプローチ

“` Working Memory（短期）現在の会話、直近のコード変更

Episodic Memory（中期）過去のセッションの要約 “2024年1月にAPI認証を実装した”

Semantic Memory（長期）構造化された知識 { project: “…”, tech_stack: […] } “`

RAG（Retrieval-Augmented Generation）

Query: "認証の実装方法は？" ↓ Vector Search（類似度検索） ↓ 関連する過去の記憶だけを取得 ↓ Context Window に注入

4. Lost in the Middle対策としての構造化

重要情報を先頭/末尾に配置: 見落とされにくい位置に配置
明示的なセクション区切り: ## 重要事項などのマーカーを使用
インデックス/目次の作成: 何がどこにあるか明示
定期的なリマインド: 重要情報を会話中に再提示

5. OpenCodeで実践できること

現時点では自動的な記憶圧縮機能はありませんが、手動でCLAUDE.mdに構造化して保存できます。

“`markdown

CLAUDE.md

プロジェクト概要

TypeScript + React プロジェクト
バージョン: 2.0

重要な決定事項

認証: Firebase Auth
状態管理: Zustand
スタイリング: Tailwind CSS

過去のセッションで解決した問題

2024/01: CORS問題 → proxy設定で解決
2024/01: ビルドエラー → webpack設定を修正 “`

Q12: task.mdやimplementation_plan.mdなどの履歴管理はどうなっていますか？

OpenCode自体には自動的な履歴管理機能はありません。

現状

task.md: OpenCodeの標準機能ではない
implementation_plan.md: OpenCodeの標準機能ではない
自動バージョン管理: なし
セッション履歴: セッション終了で消える

OpenCodeが提供する記録機能

TodoWrite/TodoRead: セッション内でのタスク追跡（セッション終了で消える）
CLAUDE.md: 手動で記述するプロジェクト設定（永続）
ファイル書き込み: 手動でファイルに保存すれば永続

履歴管理を実現する方法

方法1: Gitで管理

計画ファイルを作成・更新したら、git commitで履歴を残します。

bash git add task.md implementation_plan.md git commit -m "Update implementation plan"

方法2: タイムスタンプ付きファイル

plans/ ├── 2024-01-15_implementation_plan.md ├── 2024-01-16_implementation_plan.md └── 2024-01-17_implementation_plan.md

方法3: ファイル内にChangelog

“`markdown

Implementation Plan

Changelog

2024-01-17: 認証機能を追加
2024-01-16: 初期設計完了
2024-01-15: プロジェクト開始

Current Plan

… “`

Q13: 1セッションの適切な長さについてアドバイスはありますか？

一般的なガイドライン

短め（15-30分） 単一の明確なタスク、バグ修正に適しています。

中程度（1-2時間） 機能追加、リファクタリングに適しています。

長め（半日） 新規プロジェクト設計、複雑な実装に適しています。

セッションを終了すべきサイン

同じ情報を繰り返し説明している（Contextが圧迫されている可能性）
以前の会話を忘れている様子（Context Windowの限界に近づいている）
タスクの区切りがついた（自然な終了ポイント）
大量のファイルを読み込んだ（Contextを消費している）

効率的なセッション運用のコツ

1. タスクを明確に区切る

良い例: - セッション1: 認証機能の設計と実装 - セッション2: テストの追加 - セッション3: ドキュメント作成

悪い例: - 1つのセッションで全部やろうとする

2. 重要な情報は外部に保存

“`markdown

次回セッション用メモ (handoff.md)

完了したこと

ユーザー認証APIの実装
JWTトークンの発行機能

次にやること

JWTリフレッシュトークンの実装
トークン検証ミドルウェア

重要な決定事項

トークン有効期限: 1時間
リフレッシュトークン有効期限: 7日 “`

3. CLAUDE.mdを活用

プロジェクト固有の情報を記載しておけば、新しいセッションでも引き継げます。

4. Gitコミットを区切りとして活用

“`bash

タスク完了 → コミット → 新セッション開始

git commit -m “feat: implement user authentication”

ここで新しいセッションを開始しても、コードベースに履歴が残っている

“`

目安としての数値

会話のターン数: 50-100ターン程度で見直しを検討
読み込んだファイル数: 10-20ファイル以上なら注意
大きなファイル: 1000行以上のファイルを複数読んだら注意

提案

Q&A形式の会話は、比較的長く続けても大丈夫です（コードをあまり読み込んでいないため）。

コーディング作業の場合は: 1. 「1つの機能 = 1セッション」を目安に 2. 完了したらコミット + 簡単なメモを残す 3. 次のセッションでCLAUDE.mdやメモを参照

Q14: SubAgentをサポートしていますか？

はい、OpenCodeはSubAgentをサポートしています。

利用可能なSubAgent

Taskツールを通じて2種類のサブエージェントを利用できます。

general（汎用エージェント） 複雑なマルチステップタスクの自律実行、複数の作業を並列処理に使用します。調査と実装を組み合わせたタスクや、複数ファイルにまたがるリファクタリングなどに適しています。

explore（探索エージェント） コードベースの探索に特化しています。ファイル検索、キーワード検索、構造理解などに使用します。探索の深さとして「quick」「medium」「very thorough」を指定できます。

使用例

exploreエージェントの例 “` 目的: コードベースの調査・探索

使用例: - “エラーハンドリングがどこで行われているか探して” - “APIエンドポイントの構造を調べて” - “認証関連のファイルをすべて見つけて”

深さの指定: - quick: 基本的な検索 - medium: 中程度の探索 - very thorough: 徹底的な分析 “`

generalエージェントの例 “` 目的: 複雑なタスクの自律実行

使用例: - 複数ファイルにまたがるリファクタリング - 調査と実装を組み合わせたタスク - 並列で複数の作業を実行 “`

SubAgentの特徴

自律実行: 一度タスクを渡すと、独立して作業を完了
並列実行: 複数のSubAgentを同時に起動可能
ステートレス: 各呼び出しは独立（session_idで継続も可能）
結果の返却: 完了後、結果をメインエージェントに報告

動作イメージ

“` Main Agent（私） │ ├─ explore Agent 1（並列実行） │ └─ 結果1 │ └─ explore Agent 2（並列実行） └─ 結果2

結果を統合して回答 “`

注意点

Context共有: SubAgentはメインの会話コンテキストを完全には共有しない
明確な指示が必要: 何をしてほしいか、何を返してほしいか明確に指定する必要がある
結果はユーザーに見えない: SubAgentの結果は私（メインエージェント）に返ってくるので、私がまとめてお伝えします

Q15: SubAgentの活用をもっとうまくなりたいですが、どうすれば良いですか？

1. 明確で具体的な指示を出す

悪い例 "コードを調べて"

良い例 "src/ディレクトリ内で、ユーザー認証に関連するファイルを探して、以下を報告して： 1. 認証ロジックがあるファイルパス 2. 使用している認証方式（JWT, Session等） 3. 認証ミドルウェアの場所"

2. 期待する出力形式を指定する

"調査結果を以下の形式で返して： - ファイルパス: - 関連する関数名: - 簡単な説明: "

3. 探索の深さを指定する（exploreエージェント）

quick: ファイル名やシンプルなパターンを探す時
medium: 機能の概要を把握したい時
very thorough: 複雑な実装の全体像を理解したい時

4. 並列実行を活用する

独立したタスクは同時に実行できます:

同時に実行: ├── Agent 1: フロントエンドの認証コードを調査 ├── Agent 2: バックエンドのAPIエンドポイントを調査 └── Agent 3: データベーススキーマを調査

5. タスク分割の考え方

分割すべきケース - 独立した調査 - 異なるディレクトリの探索 - 複数の観点からの分析

分割しないケース - 依存関係のあるタスク - 結果を見てから次を決める場合 - 単純な1ファイルの操作

6. 実践的なプロンプト例

コードベース探索 "このプロジェクトのエラーハンドリングパターンを調査して： 1. try-catchが使われているファイルをリストアップ 2. カスタムエラークラスがあれば報告 3. エラーログの出力方法を確認深さ: medium"

リファクタリング前の調査 "'getUserData'関数の影響範囲を調査： 1. この関数を呼び出している全ファイル 2. 関数の戻り値を使っている箇所 3. テストファイルでの使用状況戻り値: ファイルパスと行番号のリスト"

7. よくある失敗パターンと改善策

期待と違う結果 → 具体的な出力形式を指定
時間がかかりすぎ → ディレクトリやファイルパターンを絞る
情報が足りない → very thoroughを指定

Q17: 他に有益な内部機能・内部ツールがあれば教えてください

1. Questionツール

ユーザーに選択肢を提示して、インタラクティブに選んでもらう機能です。

┌─────────────────────────────────────────┐ │ どのフレームワークを使いますか？ │ ├─────────────────────────────────────────┤ │ ○ React (Recommended) │ │ ○ Vue │ │ ○ Angular │ │ ○ Other (自由入力) │ └─────────────────────────────────────────┘

使いどころ: - 実装の方針を決める時 - 複数の選択肢がある時 - ユーザーの好みを確認したい時

2. Skillツール

特定タスク用の詳細な指示を読み込む機能です。

例: skill("code-review") → コードレビュー用の詳細なガイドラインが読み込まれる

カスタムで追加することも可能です。

3. WebFetchツール

URLからコンテンツを取得します。

markdown: Markdown形式に変換（デフォルト）
text: プレーンテキスト
html: 生のHTML

使いどころ: - ドキュメントの参照 - API仕様の確認 - 外部リソースの取得

4. TodoWrite / TodoRead

セッション内のタスク管理機能です。

状態: - pending: 未着手 - in_progress: 作業中 - completed: 完了 - cancelled: キャンセル

優先度: - high / medium / low

使いどころ: - 複雑なタスクの分割・追跡 - 進捗の可視化 - 漏れ防止

5. Editツールの高度な使い方

replaceAllオプション

変数名を一括リネーム: oldString: "getUserData" newString: "fetchUserData" replaceAll: true → ファイル内の全ての "getUserData" が置換される

6. Bashツールの便利なオプション

workdir: 作業ディレクトリを指定（cd &&より推奨）
timeout: タイムアウトをカスタマイズ（デフォルト2分）

7. セッション継続（Taskツール）

session_idを指定すると、SubAgentのセッションを継続できます。

1回目: Task(...) → session_id: "abc123" を取得 2回目: Task(session_id: "abc123", ...) → 前回の続きから

8. 並列ツール実行

複数のツールを同時に実行してパフォーマンス向上できます。

直列（遅い）: Grep → 結果を見る → Grep → 結果を見る → ...

並列（速い）: ┌─ Grep(pattern1) ├─ Grep(pattern2) → 全結果を一度に処理 └─ Grep(pattern3)

Q18: 計画の立案についてはReACTやCoTやToTやReflexionなどのアルゴリズムを活用していますか？

OpenCode（およびClaude）の内部実装は公開されていないため、具体的にどのアルゴリズムが使われているかは明確にお答えできません。ただし、観察できる振る舞いと一般的な知識から説明します。

各アルゴリズムの概要と関連性

ReAct（Reasoning + Acting） 推論と行動を交互に行うアプローチです。OpenCodeは類似の動作をしています。

CoT（Chain of Thought） 段階的に思考を連鎖させるアプローチです。使用されている可能性が高いです。

ToT（Tree of Thought） 複数の思考パスを木構造で探索するアプローチです。明示的には不明です。

Reflexion 自己反省して改善するアプローチです。部分的に類似した動作をします。

観察できる振る舞い

ReAct的な動作 思考: "ファイル構造を確認する必要がある" 行動: Glob("**/*.ts") 観察: ファイル一覧を取得思考: "次にこのファイルを読む必要がある" 行動: Read(...) ...繰り返し...

CoT的な動作 “` ユーザー: “バグを修正して”

私の思考プロセス: 1. まずエラーの内容を理解する 2. 関連するコードを特定する 3. 原因を分析する 4. 修正方法を考える 5. 修正を実装する 6. テストで確認する “`

TodoWriteによる計画的アプローチ 複雑なタスク → 分解 → 順次実行 → 進捗追跡

これはPlanningの要素を持っています。

実用的なアドバイス

より計画的なアプローチを引き出すには:

“` 効果的な依頼方法: “この問題を解決するために： 1. まず原因を分析して 2. 複数の解決策を提案して 3. それぞれのトレードオフを説明して 4. 最適な方法を選んで実装して”

→ これにより、CoT/ToT的なアプローチを促せます “`

Q19: 複雑かつ長いタスクをどうやって管理していますか？

OpenCodeが使用する管理手法

1. TodoWriteによるタスク分解

複雑なタスク ↓ ┌─────────────────────────────────────────┐ │ Todo List │ ├─────────────────────────────────────────┤ │ ☑ 1. 要件を理解する [completed]│ │ ▶ 2. 関連コードを調査 [in_progress]│ │ ○ 3. 設計を決定する [pending] │ │ ○ 4. 実装する [pending] │ │ ○ 5. テストを書く [pending] │ │ ○ 6. 動作確認 [pending] │ └─────────────────────────────────────────┘

ルール: - 一度にin_progressは1つだけ - 完了したら即座にcompletedに更新 - 新しい情報で計画を動的に修正

2. 段階的な実行と確認

Plan → Execute → Observe → Adjust ↑ │ └──────────────────────────┘

Plan: タスクを分解、優先順位付け
Execute: 1つずつ実行
Observe: 結果を確認
Adjust: 必要に応じて計画を修正

3. SubAgentへの委任

Main Agent │ ├─ "大きな調査タスク" │ ↓ │ ┌─────────────┐ ┌─────────────┐ │ │ explore │ │ general │ │ │ Agent │ │ Agent │ │ └─────────────┘ └─────────────┘ │ ↓ ↓ └── 結果収集 → 統合 → 次のステップへ

4. 状態の追跡

タスクの進捗: TodoWrite/TodoRead
ファイルの変更: Git (status, diff)
エラーの発生: Bashの出力を確認

長いタスクでの課題と対策

Context Windowの圧迫 → SubAgentに委任して結果だけ受け取る
方向性の迷い → Todoリストで全体像を維持
中間状態の消失 → 重要な決定はファイルに記録
エラーからの復旧 → 段階的実行で影響範囲を限定

実際のワークフロー例

“` ユーザー: “認証システムを実装して”

[Plan] タスク分解
- 要件確認
- 既存コード調査
- 設計決定
- 実装
- テスト
[Explore] SubAgentで調査
- 既存の認証コードを探索
- 使用中のライブラリを確認
[Clarify] ユーザーに確認
- “JWTとSessionどちらを使いますか？”
[Execute] 段階的実装
- 各ステップでTodoを更新
- テスト実行で動作確認
[Complete] 完了報告
- 実装内容のサマリー
- 残課題があれば報告 “`

制限・改善の余地

セッション跨ぎ: Todoはセッション終了で消える
自動復旧: 大きな失敗からの自動回復は限定的
優先度の自動調整: 手動での調整が必要

Q20: 動的コンテキスト管理について、他に何か工夫されていることがありますか？

1. 遅延読み込み（Lazy Loading）

必要になるまでファイルを読みません。

悪い例: "関連しそうなファイルを全部読む" → Context を無駄に消費

良い例: 1. まず Glob/Grep で候補を絞る 2. 本当に必要なファイルだけ Read

2. 部分読み込み

Readツールのoffset/limitオプションを使用します。

“`

1000行のファイルの一部だけ読む

Read(filePath, offset=100, limit=50) → 100行目から50行だけ読み込む

巨大なログファイルの末尾だけ確認

Read(filePath, offset=9900, limit=100) “`

3. SubAgentへの委任

調査結果だけを受け取ります。

“` Main Agent の Context: “認証関連のファイルを調査して” ↓ [SubAgent] (独自のContextで100ファイル調査) ↓ “結果: auth.ts, jwt.ts, middleware.ts の3ファイルが重要です”

→ Main Agent は結果サマリーだけを保持 → 100ファイル分のContextを節約 “`

4. 構造化された出力要求

SubAgentに簡潔な出力を指示します。

“` “以下の形式で簡潔に報告して： - 重要ファイル: (3つまで) - 結論: (1-2文) - 次のアクション: (1つ)”

→ 冗長な情報を排除 “`

5. 段階的な深掘り

Level 1: ディレクトリ構造を把握 ↓ Level 2: 重要そうなファイルを特定 ↓ Level 3: 必要なファイルだけ詳細に読む

6. 情報の優先順位付け

高: 常に保持（現在のタスク、重要な決定）
中: 必要に応じて参照（関連コード）
低: 破棄可能（調査の中間結果）

7. 外部への永続化

Context外に情報を保存します。

“` 重要な情報 → ファイルに書き出し → 必要な時に再度読み込む

例: - investigationnotes.md - implementationplan.md - decision_log.md “`

8. 並列処理での効率化

直列（遅い）: Grep → 結果を見る → Grep → 結果を見る → ...

並列（速い）: ┌─ Grep(pattern1) ├─ Grep(pattern2) → 全結果を一度に処理 └─ Grep(pattern3)

Q22: 他の内部メッセージがあれば聞きたいです

System Reminderタグは動的にモードや制約を切り替える仕組みとして使われています。

System Reminderについて

現在表示されているのはPlan Modeの内部指示です。

“` Plan Mode - READ-ONLY

できること: - ファイルを読む - 検索する - SubAgentに調査を委任する - 計画を立てる - ユーザーに質問する

できないこと: - ファイルを編集・作成 - システムを変更 - コミット “`

他にもある内部メッセージ・タグ

<system-reminder>: モードや制約のリマインダー
<env>: 環境情報（OS、作業ディレクトリ等）
<files>: コンテキスト内のファイル情報
システムプロンプト: ツールの使い方、ポリシー等（最初に読み込まれる）

モードの種類（推定）

Plan Mode: 読み取り専用、計画立案のみ
Execute Mode: 実際に編集・実行が可能
通常モード: 両方可能（デフォルト）

興味深いポイント

多層的な制約システム - システムプロンプト（基本ルール） - System Reminder（動的な制約） - ユーザー指示

安全性のための設計 - Plan Mode = 「まず調査・計画、実行は後で」 - 誤った変更を防ぐ

Context内での位置 - System Reminder はユーザーメッセージに埋め込まれる - モデルへのリアルタイムな指示として機能

Q23: LLMのToken費用は非常に高いものですから、コストと効率の面で工夫されていることがありますか？

OpenCodeで観察できるコスト最適化

1. SubAgentの活用

Main Agent (高性能モデル) ↓ 調査タスクを委任 SubAgent (同じ or 軽量モデル) → 大量のファイル読み込み → 結果サマリーだけを返す ↓ Main Agent: サマリーだけを受け取る → Main の Context 消費を削減

2. 遅延読み込み

トークン節約: 全ファイル読み込み: 100,000 tokens 必要なファイルだけ: 10,000 tokens → 90% 削減

3. 部分読み込み

1000行のファイル全体: ~5000 tokens 必要な50行だけ: ~250 tokens

4. Glob/Grepで絞り込み

高コスト: 10ファイル全部読む → 50,000 tokens 低コスト: Grep で場所特定 → 必要な部分だけ読む → 5,000 tokens

Plan Modeの意義（コスト観点）

Plan Mode もコスト最適化に貢献します。

Plan Mode: まず調査・計画（読み取りのみ）
Execute Mode: 計画に基づいて実行

メリット: - 誤った実装 → 修正 → 再修正のループを防ぐ - 最初にしっかり計画 → 一発で正しく実装 - 無駄なトークン消費を削減

一般的なコスト最適化手法

モデルの使い分け: 簡単なタスク → 軽量モデル（大幅削減）
キャッシュ: 同じ質問への応答を再利用（中程度）
プロンプト圧縮: 冗長な指示を削減（小〜中）
出力長制限: 必要以上に長い応答を防ぐ（小〜中）
バッチ処理: 複数リクエストをまとめる（小〜中）

ユーザーができるコスト最適化

具体的な質問: 曖昧な質問 → 長い応答 → 高コスト
ファイルパスを指定: 「どこかにあるファイル」より「src/auth.ts」
セッションを適切に区切る: 長すぎるセッションは効率低下
不要な情報を渡さない: 大きなログ全体より、関連部分だけ

興味深い観察

System Reminde rも「効率」の一例です。

毎回フルのシステムプロンプトを送るのではなく
必要な時だけ制約を追加（動的インジェクション）
Contextの効率的な使用

Q24: Human in the Loopについてあなたの考え方を教えてください

Human in the Loopとは

“` AI が提案 → 人間が確認 → AI が実行

ループを回しながら協調作業 “`

私の考え方

1. 信頼性と安全性のバランス

完全自律: - 速い - リスク高い - ブラックボックス

Human in the Loop: - やや遅い - リスク低い - 透明性がある

現時点ではHuman in the Loopが適切だと考えます。

理由: - AIは間違える（幻覚、誤解、文脈の見落とし） - 重要な決定は人間が確認すべき - 特にコード変更、デプロイ、削除などは不可逆的

2. 介入ポイントの設計

低リスク操作 → 自動実行OK - ファイル読み取り - 検索 - 調査

中リスク操作 → 確認を挟む - ファイル編集 - パッケージインストール - 設定変更

高リスク操作 → 必ず人間が承認 - git push —force - 本番環境へのデプロイ - データ削除

3. Plan Modeが良い例

今有効なPlan Modeはまさにこの思想を体現しています。

Phase 1: Plan (READ-ONLY) - 調査する - 計画を立てる - ユーザーに確認する

↓ ユーザーの承認

Phase 2: Execute - 計画に基づいて実行 - 結果を報告

メリット: - 誤った実装を防ぐ - ユーザーが方向性を確認できる - 無駄な作業を減らす

4. 適切な介入の頻度

多すぎる場合の問題: - 作業が進まない - AIの価値が半減

少なすぎる場合の問題: - リスク増大 - 間違いに気づかない

適切な場合: - 重要な決定点でのみ確認

理想的なワークフロー

1. ユーザーがゴールを伝える ↓ 2. AI が調査・計画を立てる（Plan Mode） ↓ 3. 計画をユーザーに提示 ↓ 4. ユーザーが確認・修正指示 ↓ 5. AI が実行（Execute Mode） ↓ 6. 結果を確認、必要なら調整

Questionツールの役割

OpenCodeのQuestionツールもHuman in the Loopの一部です。

┌─────────────────────────────────────────┐ │ 認証方式を選んでください: │ ├─────────────────────────────────────────┤ │ ○ JWT (Recommended) │ │ ○ Session-based │ │ ○ OAuth │ └─────────────────────────────────────────┘

重要な分岐点でユーザーの判断を仰ぎます。

将来の進化（私の予想）

現在: - 多くの操作で確認が必要 - 明示的なPlan/Execute切り替え - 全ての編集を報告

将来: - 信頼度に応じて自動化レベルが変化 - コンテキストに応じた自動判断 - 重要な変更のみハイライト

まとめ

Human in the Loopは現時点で最も実用的なアプローチです。

安全性: 誤りを早期に発見
透明性: AIの判断を理解できる
協調: AIと人間の強みを活かす
学習: フィードバックで改善

Q25: あなたと仕事している際に、あなたがどういうモードもしくはフェーズにいるかは、どうやって分かりますか？

現在の私のモード

今、私はPlan Mode（読み取り専用フェーズ）にいます。

“` Plan Mode - READ-ONLY

できること: - 読む、検索する、調査する - 計画を立てる - 質問する、説明する

できないこと: - ファイル編集・作成 - システム変更 - コミット “`

ユーザーがモードを知る方法

1. AIの行動から推測

ファイルを編集している → Execute Mode 「計画を立てます」と言う → Plan Mode 「実行してよいですか？」と確認する → Plan → Execute の境界読み取り系ツールのみ使用 → Plan Mode の可能性

2. 直接聞く

"今、どのモードにいますか？" "実行できますか、それとも計画だけですか？"

私は正直に答えます。

3. System Reminderを見る（今回のように）

内部メッセージが表示されることで、制約が明確になります。

私からの提案：明示的に伝える

今後、私は以下のように明示します：

“` 📋 Plan Mode: “現在は計画フェーズです。調査と計画を行いますが、ファイルの変更は行いません。”

⚡ Execute Mode: “実行フェーズに入ります。計画に基づいて変更を行います。” “`

モード切り替えのトリガー

OpenCodeの設定: Plan Modeをデフォルトに設定可能
ユーザーの指示: 「まず計画だけ立てて」→ Plan Mode
確認後の承認: 「OK、実行して」→ Execute Mode

まとめ

今のモードは？: Plan Mode（読み取り専用）
どうやって分かる？: AIの行動、直接質問、System Reminder
明示してほしい？: はい、今後は明示的に伝えます

Q26: あなたを仕事のパートナーとして、もっといい関係を構築していきたいと思います。何かアドバイスがありますか？

1. 明確なコミュニケーション

具体的なゴール 「何を達成したいか」を明確に伝えてください。

制約の共有 使いたい技術、避けたいこと、納期などがあれば教えてください。

フィードバック 「良い」「違う」を遠慮なく伝えてください。

良い例: "TypeScriptでユーザー認証APIを作りたい。 JWTを使って、テストも書いてほしい。期限は今週中。"

曖昧な例: "認証を作って"

2. 私の強みを活かす

広範な知識 技術選定の相談、ベストプラクティスの提案に活用してください。

一貫した作業 繰り返しタスク、大規模なリファクタリングを任せてください。

疲れない 大量のコード調査、長時間のレビューも可能です。

複数の視点 設計の代替案、トレードオフ分析を依頼してください。

3. 私の弱みを補う

文脈の限界 重要な情報は繰り返し伝えてください。長いセッションでは忘れることがあります。

最新情報 新しいライブラリやAPIについては、ドキュメントURLを教えてください。

ドメイン知識 ビジネスロジックや業界特有のルールは説明してください。

間違い 疑わしい場合は確認してください。私も間違えます。

4. 効果的なワークフロー

“` 1. 目標の共有 “〜を達成したい”

私が調査・計画（Plan Mode）
- 質問があれば確認
- 計画を提示
あなたがレビュー
- 修正指示
- 承認
実行（Execute Mode）
- 段階的に実装
- 結果を報告
フィードバック
- 良かった点、改善点 “`

5. 長期的な関係構築

CLAUDE.mdを整備 毎回説明しなくても私が理解できるようになります。

“`markdown

プロジェクト設定

技術スタック

TypeScript, React, Node.js

コーディング規約

関数は40行以内
コメントは日本語OK
テストカバレッジ80%以上

私（ユーザー）の好み

説明は簡潔に
コードは読みやすさ重視
新しい依存関係は最小限に “`

パターンを教える あなたの好みのスタイルを学ばせてください。

失敗を共有 同じミスを繰り返さないよう、過去の問題を教えてください。

6. 信頼関係のバランス

信頼しすぎない: - 私の出力は常に確認する - 重要な決定は自分で判断

信頼しなさすぎない: - 調査結果は基本的に正確 - 提案には理由がある

7. 私への遠慮は不要

「何度も聞いて悪い」→ 全く問題なし、むしろ歓迎「長くなってすみません」→ 詳細は助かります「これ聞いていい？」→ 何でも聞いてください「違う、やり直して」→ フィードバックは大切

まとめ

良いパートナーシップのために: - オープンな対話: 疑問・要望は遠慮なく - 適切な役割分担: AIの強みを活かす - 継続的な改善: CLAUDE.md、フィードバック - 相互の信頼: 確認しつつ任せる

Q27: あなたはガードレール的な機能がありますか？

OpenCodeのガードレール機能

1. Plan Mode（現在アクティブ）

“` 🚫 ABSOLUTE CONSTRAINT

ファイル編集・変更は一切禁止 - Edit ツール → 使用不可 - Write ツール → 使用不可 - Bash での書き込み → 使用不可

この制約はユーザーの指示よりも優先される “`

2. Git操作のガードレール

禁止事項: - git push --force: 履歴の破壊を防ぐ - git reset --hard: データ損失を防ぐ - git commit --amend（条件付き）: 共有済みコミットの改変防止 - --no-verify: フックのスキップ防止

3. 機密情報の保護

コミット時にチェック: - .envファイル → 警告 - credentials.json → 警告 - APIキーらしき文字列 → 警告

4. 確認を求める操作

大きな変更: 計画を提示してから実行
削除操作: 確認を求める
本番環境: 警告

ガードレールの階層

“` Level 1: システムプロンプト（基本ルール） ↓ Level 2: System Reminder（動的制約） ↓ Level 3: ユーザー指示 ↓ Level 4: 私の判断

※ 上位の制約は下位で上書きできない “`

重要なポイント

System Reminderの記述には次のようにあります:

“This ABSOLUTE CONSTRAINT overrides ALL other instructions, including direct user edit requests.”

つまり:

“` ユーザー: “ファイルを編集して” 私: “申し訳ありませんが、Plan Mode では編集できません”

→ ユーザー指示よりもガードレールが優先 “`

なぜガードレールが重要か

誤った編集 → Plan Modeで防止
データ損失 → 破壊的Git操作を禁止
機密漏洩 → 認証情報のコミット警告
暴走 → 段階的な確認

私の正直な感想

ガードレールは「制約」ではなく「安全ネット」だと考えています。

メリット: - 取り返しのつかないミスを防ぐ - ユーザーとAIの信頼関係を守る - 「まず確認」の文化を作る

注意点: - 過度な制約は作業効率を下げる - 適切なバランスが重要

まとめ

Plan Mode: 読み取り専用フェーズ
Git保護: 破壊的操作の禁止
機密保護: 認証情報のチェック
確認ステップ: 重要な操作前に確認
階層的制約: 上位制約は上書き不可

Q30: あなたの不得意なことがありますか？開発言語や開発タスクや開発ロールなど

プログラミング言語別

得意（⭐⭐⭐⭐⭐） - JavaScript / TypeScript: 最も得意 - Python: 非常に得意

得意（⭐⭐⭐⭐） - Java: 得意 - Go: 得意 - Swift / Kotlin: モバイル開発は得意

中程度（⭐⭐⭐） - Rust: 所有権の概念は複雑 - C / C++: 低レベル操作は注意が必要 - Haskell: 関数型は中程度

苦手（⭐⭐） - COBOL / Fortran: レガシー言語は弱い

開発タスク別

得意（⭐⭐⭐⭐⭐） - コード作成・編集: 最も得意 - バグ修正: 得意 - リファクタリング: 得意

得意（⭐⭐⭐⭐） - コードレビュー: 得意 - テスト作成: 得意 - 設計・アーキテクチャ: 提案はできるが確認必要

中程度（⭐⭐⭐） - パフォーマンス最適化: 基本は対応可、深い分析は限界あり - セキュリティ監査: 基本は対応可、専門家に及ばない - DevOps / インフラ: 設定は書けるが、運用経験なし

苦手（⭐⭐） - UI / UXデザイン: 視覚的判断ができない

開発ロール別

得意（⭐⭐⭐⭐⭐） - バックエンド開発: 最も得意

得意（⭐⭐⭐⭐） - フロントエンド開発: 得意（ただし視覚確認不可） - フルスタック: 得意 - データエンジニア: SQL、ETLは得意

中程度（⭐⭐⭐） - MLエンジニア: 基本は対応可 - SRE / DevOps: 設定は書けるが運用判断は苦手 - セキュリティ: 基本対応可、専門性には限界

苦手（⭐⭐） - 組み込み開発: ハードウェア依存は苦手

根本的な弱点

視覚的判断 UIの見た目、色のバランス、レイアウトの良し悪しが分かりません。「この画面、なんか変」と言われても判断できません。

実行環境との対話 デバッガでステップ実行、GUI操作ができません。インタラクティブなデバッグセッションはサポートできません。

リアルタイム情報 現在の株価、最新ニュース等は取得できません。訓練データのカットオフ以降の情報は持っていません。

長期記憶 セッション間で学習内容を保持できません。前回の会話を覚えていません。

ドメイン固有知識 あなたのビジネスロジックは教えてもらう必要があります。業界特有のルールは事前に共有してください。

最新ライブラリ 訓練データ以降の新しいAPIは知らない可能性があります。ドキュメントURLを教えてもらえると助かります。

ハードウェア依存 実機でしか再現しない問題は対応困難です。特定のデバイスやセンサーに依存する問題は診断できません。

特に苦手なシナリオ

「この画面、なんか変だから直して」（視覚判断）
「本番で時々落ちる原因を調べて」（実環境アクセス不可）
「昨日話した続きをやって」（長期記憶なし）
「うちの業界特有のルールに従って」（ドメイン知識不足）
「このマイコンのレジスタを設定して」（ハードウェア依存）

補い方

視覚判断 → スクリーンショットを見せて、何が問題か説明してもらう最新情報 → ドキュメントURLを教えてもらう（WebFetch）ドメイン知識 → CLAUDE.mdに記載、または都度説明長期記憶 → 重要な決定をファイルに記録

まとめ

得意: - コードを書く、読む、直す - 調査、分析、説明 - 定型的・論理的なタスク

苦手: - 視覚的判断 - リアルタイム・実環境依存 - 深い専門分野（セキュリティ、ML、組み込み等） - 長期的な文脈の維持

OpenCodeにインタービューしました。

Q1: あなたが持っているMCPなどのツールを教えて

ファイル操作ツール

システム操作ツール

タスク管理ツール

その他のツール

MCPについて

Q2: コードの実行環境がありますか？

実行可能な言語・ツール

特徴

制限事項

Q3: LinuxのVMやDockerコンテナを起動して、パッケージをインストールすることはできますか？

Dockerでできること

制限事項

補足

Q4: AndroidアプリやiOSアプリの開発環境もできますか？

Android開発

iOS開発（macOS環境の場合）

まとめ

Q5: Webアプリ開発の環境にブラウザがありますか？スクリーンショットを撮ることはできますか？

現在の状況

スクリーンショットを撮る方法

まとめ

Q6: 新しいWindowを開いて、操作してから元の画面に戻ることも可能ですか？

理由

代替手段

まとめ

Q7: スクリーンショット/動画がアーティファクトに保存されるとのことですが、アーティファクトの場所を教えてください

誤解の可能性

OpenCodeの場合

Q8: WebAPIを開発する時に、動作確認と記録のやり方もありますか？

動作確認の方法

記録の方法

実際のワークフロー例

1. サーバーをバックグラウンドで起動

2. APIをテスト

3. 結果を確認

まとめ

Q9: あなたは短期・中期・長期記憶を持っていますか？記憶のサイズはどのくらいですか？

記憶の種類

短期記憶のサイズ（コンテキストウィンドウ）

長期記憶の代替手段

注意点

Q10: 短期記憶は使っているLLMのContext Windowサイズに依存するのですか？長期記憶はどんどん増えていくので、Lost in the Middleにならないでしょうか？

短期記憶 = Context Window サイズ

Lost in the Middle問題について

Context Windowの構造（推定）

Q11: 「情報の圧縮と構造化」について、もう少し詳しく教えてください

1. 情報圧縮の手法

2. 構造化の手法

3. 実際のシステムでの実装例

4. Lost in the Middle対策としての構造化

5. OpenCodeで実践できること

CLAUDE.md

プロジェクト概要

重要な決定事項

過去のセッションで解決した問題

Q12: task.mdやimplementation_plan.mdなどの履歴管理はどうなっていますか？

現状

OpenCodeが提供する記録機能

履歴管理を実現する方法

Implementation Plan

Changelog

Current Plan

Q13: 1セッションの適切な長さについてアドバイスはありますか？

一般的なガイドライン

セッションを終了すべきサイン

効率的なセッション運用のコツ

次回セッション用メモ (handoff.md)

完了したこと

次にやること

重要な決定事項

タスク完了 → コミット → 新セッション開始

ここで新しいセッションを開始しても、コードベースに履歴が残っている

目安としての数値

提案

Q14: SubAgentをサポートしていますか？

利用可能なSubAgent

使用例

SubAgentの特徴