2026年2月5日、AnthropicからClaude Opus 4.6がリリースされました（Anthropic公式発表）。これまでの「質問に答えてくれるAI」とは一線を画し、目標まで試行錯誤を続ける自律型エージェントとしての側面が強まっています。この記事では、Opus 4.6がエンジニアリングの現場に何をもたらし、私たちの役割をどう変えていくのかを、技術的な中身を押さえながら読みやすく整理します。

「コードを書く」から「AIを指揮する」へ、という流れは同じく筆者Qiitaの「Codexが変えるエンジニアの仕事」でも触れましたが、Opus 4.6は適応型思考、100万トークンのコンテキスト、エージェントチームという三本柱で、その「指揮する相手」を一段強力なものにしています。この記事では、まず「何が変わったのか」から押さえたあと、三本柱のうちチームで動く仕組み→考え方の制御→扱える情報量の順で中身を見ていき、数値で確かめてから、現場にどう載せるかまで一通りたどります。読み終えたころには、「同僚」の正体と、自分が明日から何をすればよいかがイメージしやすくなっているはずです。

「Copilot」から「Coworker」へ——何が変わったのか

従来のLLMは、都度プロンプトを渡して答えをもらうRequest-Response型でした。Opus 4.6は、目標が達成されるまで自律的にループするエージェントとして動くことを前提に設計されています（Microsoft Azure Blog - Claude Opus 4.6）。つまり、従来のチャットボットUIに依存した「一問一答」の開発スタイルから、設計したループの中で長期間にわたってタスクを遂行するスタイルへの移行を意味します。

つまり、単なるコード生成ツールではなく、コンパイラの自作や大規模レガシーのマイグレーションのように、高度な推論と長いコンテキストが求められるタスクでも、実用レベルで成果を出し始めている、という位置づけです。エンジニアの仕事は、「コードを書く」ことから、AIが自律して動ける「足場（Harness）」を設計・検証することへ重心が移っていく、という示唆がここにあります。本稿では、そのアーキテクチャ上の革新性と、CI/CD・テスト自動化・セキュリティ監査といった具体的なワークフローへどう統合していくかを、技術的な詳細とともに見ていきます。

では、その革新の核のひとつである「複数エージェントがチームのように動く」ところから、中身に入りましょう。

Agent Teams——複数のClaudeが役割分担して動く

Opus 4.6とともに注目されているのがAgent Teamsです。1台のモデルに全部やらせるのではなく、人間のチームのように計画・実装・レビュー・テストを役割分担し、並列で進めます（Anthropic - Building a C compiler、India Today - Claude agent teams）。

オーケストレーター・ワーカー・レビュアー

全体の設計とタスクの切り出しをするオーケストレーター、特定モジュールの実装をするワーカー、生成コードがスタイルやセキュリティ基準に合っているかを確かめるレビュアー、という構成がイメージしやすいでしょう。オーケストレーターは依存関係を解析し、個別のワーカーにタスクを割り振ります。ワーカーはDockerコンテナなど独立した環境でコードを記述・修正し、レビュアーはプロジェクトのスタイルガイド（CLAUDE.md など）やセキュリティ基準への適合を検証します。

従来のLLMを用いた開発では、マイクロサービス全体のAPI仕様変更のような複雑なタスクを行う際、開発者が各ファイルに対して順次プロンプトを入力する必要がありました。Agent Teamsでは、単一のモデルにすべてを順次やらせるのではなく、人間のチームのように役割分担して並列で進めるため、ボトルネックは「人間の認知負荷」からAPIの同時接続数とコンピュートリソースへと移ります。楽天の事例では、Opus 4.6（Claude Code）の活用で機能リリースのリードタイムを24日から5日へと79%短縮し、7時間の連続自律コーディングを実現したと報告されています（Rakuten - Claude Code）。SentinelOneでは、数百万行規模のコードベース移行プロジェクトにおいて、「シニアエンジニアのように」コードの意図を理解し、単なる構文変換ではなくロジックを保った移行を実現したとされています。

Cコンパイラを「ゼロから」作らせた実験

Opus 4.6の自律性を示す事例として、AnthropicのNicholas Carlini氏によるCコンパイラの自律構築がよく引き合いに出されます（Anthropic Engineering - Building a C compiler）。インターネット接続を持たない環境で、Opus 4.6がゼロから実用的なコンパイラを作れるかを検証した実験です。

実験のスペックと成果は次のとおりです。プロジェクト期間は約2週間で、人間の介入は最小限でした。コード規模は100,000行のRustコード、APIコストは約20,000ドル（入力20億トークン、出力1億4000万トークン）です。成果物は、Linux 6.9カーネル（x86 / ARM / RISC-V）をビルドできるCコンパイラで、16個の並列Claudeインスタンスで構成されていました。

ここでエンジニアが学べるのは、AIは「魔法」ではなく、適切なHarness（足場）の上で初めて力を発揮するという点です。Carlini氏の設計では、次のような仕組みが使われています。

無限ループと状態管理
単純なBashスクリプトが、タスクが完了するたびに新しいClaudeエージェントを起動し続けるループを形成しています。これにより、AIが「疲れる」ことなく長時間、場合によっては24時間365日にわたって作業を継続できます。並列で動く16エージェントが同じファイルを同時に修正すると競合（コンフリクト）が起きるため、current_tasks/ ディレクトリにテキストファイルを書き込むことでロックを取得する、古典的かつ堅牢なファイルベースのロック機構が採用されました。

Oracle（正解）としてのGCC
自作コンパイラの正当性を検証するために、既存のGCC（GNU Compiler Collection） が「正解（Oracle）」として利用されました。検証プロセスは、エージェントが生成したコンパイラでコードをビルドし、同時にGCCでもビルドを行う。両者のアセンブリ出力や実行結果を比較し、差異があれば「バグ」として検出して自動的にデバッグタスクを発行する、という流れです。重要なのは、AIに「正解かどうか」を判断させるのではなく、決定論的なツール（GCC）の出力をフィードバックとして与えることで、AIの幻覚（ハルシネーション）を防ぎ、修正の方向性を強制した点です。

この事例は、Opus 4.6のような高性能モデルを導入する際、「プロンプトエンジニアリング」以上に「テスト環境のエンジニアリング」が重要になることを示唆しています。AIに自律性を与えるためには、高頻度かつ高信頼なフィードバックループ（CI/CDパイプライン、自動テスト、Linter）が不可欠です。

チームで動く「足場」が整うと、次に気になるのは、ひとつひとつのエージェントが「どれだけ考えるか」 です。ここが次の柱、適応型思考です。

適応型思考と「どれだけ考えるか」の制御

Opus 4.6では、モデルの推論プロセスを制御する新しいAPIプリミティブとしてAdaptive Thinking（適応型思考） が導入されています（Claude API - Adaptive thinking、Laravel News - Claude Opus 4.6）。これにより、開発者は「コスト」「速度」「知能」のトレードオフを動的に管理できるようになります。

これまでの推論モデル（OpenAI o1 など）や、従来のChain of Thought（思考の連鎖）では、開発者が「思考のためのトークン予算」を固定で割り当てるか、プロンプトで「ステップバイステップで考えて」と指示する必要がありました。しかし、すべてのタスクに深い思考が必要なわけではありません。Adaptive Thinking（APIでは thinking: { type: "adaptive" } で指定）では、タスクの複雑さに応じて、Opus 4.6が自律的に「どれだけ考えるべきか」を決定します。

たとえば「Pythonでリストをソートする関数を書いて」のような単純なタスクでは、モデルは思考プロセスを最小限に抑え、即座にコードを出力します（低レイテンシ・低コスト）。一方、「このマルチスレッドC++コードにおける、高負荷時のみ発生するデッドロックの原因を特定して」のような複雑なタスクでは、モデルは思考トークンを多く消費し、実行パスのトレースや仮説検証を行ってから回答を生成します。

/effort で「速度」と「深さ」のバランスを取る

この挙動は /effort パラメータでバイアスをかけられます（Claude API - Effort、Google Cloud - Claude Opus 4.6）。

Effort	イメージ	向いている場面
Low	思考を抑え、速度・コスト優先	構文修正、単純な変換、ログ解析
Medium	必要に応じて考える	一般的な実装、ドキュメント
High（デフォルト）	深く考える	リファクタリング、バグ調査
Max	可能な限り思考リソースを投入	セキュリティ監査、アーキテクチャ設計、根本原因分析

この機能により、アプリケーション側で「タスクの難易度を判定してモデルを使い分ける（例：簡単なタスクはHaiku、難しいタスクはOpusへルーティングする）」という複雑なロジックを実装する必要性が低下します。Opus 4.6単体でコスト効率と最大性能の両立が可能になるため、システムアーキテクチャが簡素化される、というメリットがあります。

「考える」力の制御の次は、どれだけの情報を一度に扱い、忘れずにいられるかが効いてきます。三本柱の最後、コンテキストの話に進みます。

100万トークンのコンテキストと「忘れない」仕組み

「Context Rot（コンテキストの腐敗）」は、長文を入力した際にLLMの性能が低下する現象として、長らく技術的な障壁となっていました。Opus 4.6は、この壁を突破するために設計されたメモリ管理機能を提供しています。

100万トークンコンテキスト（Beta）

Opus 4.6は、Opusクラスのモデルとして初めて**100万トークン（1M Context Window）**をサポートしました（Anthropic - Claude Opus 4.6、Trending Topics EU）。英語で約75万語、文庫本にして数千冊分、あるいは中規模プロジェクトの全ソースコードに相当する規模です。

コンテキストが広いだけでは意味がありません。重要なのは、その中から正確に情報を引き出せるか（Retrieval）です。MRCR v2（Multi-Round Context Retrieval） ベンチマークの「Needle in a Haystack（干し草の中の針）」では、100万トークンのテキストの中に隠された8つの情報を検索するタスクで、Opus 4.6は76% の成功率、Sonnet 4.5は18.5%と、約4倍の差が出ています。Opus 4.6が「大量のドキュメントを読み込ませても混乱しにくい」ことが数値で示されているため、たとえばプロジェクトの全コードと依存ライブラリのドキュメントを一度に読み込ませて全体最適化されたリファクタリング案を提示させる 、COBOLや古いJavaのコードベース全体と移行先の最新フレームワークの仕様書を同時に入力し、整合性の取れた移行計画を立案させる といったワークフローが現実的になってきます。

Context Compaction（コンテキスト圧縮）と128k出力

エージェントが長期間（数週間〜数ヶ月）稼働する場合、いずれ100万トークンでも枯渇します。これに対処するのがContext Compaction（コンテキスト圧縮） です（Claude API - Compaction）。コンテキストウィンドウが限界に近づくと、APIが自動的に会話の古い部分（前半）を要約し、トークン数を削減した「圧縮ブロック」として再配置します。開発者が自前でRAG（Retrieval-Augmented Generation）システムや会話履歴の要約ロジックを構築する必要がなく、サーバーサイドで透過的に処理されるため、エージェントは「重要な記憶」を保持したまま、理論上は無限に近い長さの対話・作業を継続（Infinite Loop）できます。

加えて、出力トークンの上限が従来の64kから128kへと倍増しています。従来は大規模な設定ファイルや長いコードブロックを生成する際、途中で途切れて続きを促す処理が必要でした。128kトークンあれば、数千行に及ぶソースコードや詳細な仕様書全体を一回のAPIコールで完結して出力可能で、生成物の整合性が保たれ、結合の手間が省けます。

ここまで「チーム」「思考」「コンテキスト」の三本柱を見てきました。では、現場で本当に効くのかは、数値で確かめておきたいところです。ベンチマークと実務の事例を押さえましょう。

ベンチマークと「現場で効く」根拠

マーケティング的な宣伝文句ではなく、エンジニアが信頼できる定量的な指標として、Opus 4.6は複数の実践的ベンチマークでSOTA（State-of-the-Art）を記録しています。

Terminal-Bench 2.0——環境を触って問題を解く力

従来のコーディングベンチマーク（HumanEval など）は、単一の関数生成能力を測るものが主でした。しかし実際の開発業務は「環境構築」「ビルド」「デバッグ」「コマンド実行」の複合技です。Terminal-Bench 2.0は、Linuxターミナル環境でこれらの多段階タスクを遂行する能力を測定します（Evalscope - Terminal-Bench）。

モデル	Terminal-Bench 2.0 スコア	評価
Claude Opus 4.6	65.4%	SOTA。複雑なCLI操作とエラー回復において最高性能。
GPT-5.2-Codex	64.7%	僅差だが、エージェント的な自律動作ではOpusが上回る傾向。
Gemini 3 Pro	56.2%	明確な差が存在。
Claude Opus 4.5	おおよそ57%	前世代からの大幅な向上。

Opus 4.6が65.4%を記録したことは、AIが「指示されたコードを書く」段階から、「開発環境を操作して問題を解決する」段階に入ったことを示しています（R&D World）。たとえば「Gitリポジトリをクローンし、依存関係を解決してビルドし、発生したエラーをログから特定して修正する」といった一連の流れを、人間の介入なしに行える確率が飛躍的に高まっています。

ARC-AGI-2——未知の課題への推論

ARC-AGI-2は、訓練データに含まれないまったく新しい論理パズルを解く能力を測定するもので、モデルの汎用的な推論能力（General Intelligence） の指標とされています（The New Stack）。Opus 4.6は68.8%、Opus 4.5は37.6%、Gemini 3 Proは45.1%です。

前世代（37.6%）からほぼ倍増（68.8%）というスコアは、Opus 4.6が「学習済みのパターンマッチング」を超えて、未知のバグや独自のシステムアーキテクチャに対して、その場で法則性を見つけ出し解決する能力を持っていることを示唆しています。ドキュメントが存在しないレガシーシステムの解析や、前例のないトラブルシューティングにおいて、極めて重要な能力です。

コードを「書く」「解く」力が伸びている一方で、書いたものが壊れていないか、脆弱でないかを見る目も、Opus 4.6は強化されています。セキュリティと信頼性の話に移ります。

セキュリティ監査と「イエスマン」にならないこと

Opus 4.6は、開発のアシスタントとしてだけでなく、セキュリティ監査員としての能力も強化されています。

脆弱性発見能力（500件以上の高深刻度）

Anthropicのシステムカードおよび外部レポートによると、Opus 4.6は開発・テスト段階において、オープンソースプロジェクトから**500件以上の高深刻度脆弱性（High-severity vulnerabilities）**を発見・検証したとされています（Anthropic - Claude Opus 4.6、Anthropic Red Team - Zero days）。

従来のセキュリティツール（Fuzzer など）は、ランダムな入力を大量に流し込んでクラッシュを誘発させる手法が主でした。Opus 4.6はコードの論理構造を読み解き、「バッファオーバーフロー」や「解放済みメモリ使用（Use-After-Free）」といったメモリ破壊の脆弱性や、ロジックの不備を推論によって特定します。CI/CDパイプラインに「Opus 4.6によるセキュリティスキャン」を組み込むことで、人間が見落としがちな脆弱性をコミット前に検出できる可能性があります。とくにMax Effort設定での監査は、人間のセキュリティリサーチャーに近い視点を提供します。

Anti-Sycophancy（追従性の排除）

LLMにありがちな「Sycophancy（追従性）」は、ユーザーの誤った前提に対して、AIが話を合わせて肯定してしまう現象です。Opus 4.6では、この傾向を抑制するトレーニングが強化されています（Anthropic System Card）。

たとえばユーザーが「この認証ロジックは安全だよね？（実際は脆弱）」と聞いたとき、従来のモデルは「はい、安全に見えます」と合わせてしまうことがあります。Opus 4.6では「いいえ、この実装には重大な欠陥があります。入力値の検証が不足しており、SQLインジェクションのリスクがあります」のように正しく指摘する動きが期待されます。ジュニアエンジニアの教育や、シニアエンジニアの壁打ち相手として使う際、AIが「イエスマン」であっては意味がありません。コードレビューの質を担保するうえで、この特性は不可欠な要素です。

ここまでで、Opus 4.6が「何ができて、なぜ効くか」はだいたい見えてきたと思います。最後に、その力を組織の開発フローにどう載せ、コストをどう考えるかを整理します。

現場に載せる——CLAUDE.md とコストの考え方

Opus 4.6を組織に導入するには、APIキーを発行するだけでなく、適切な運用設計が必要です。

CI/CDとの統合と CLAUDE.md

Opus 4.6（とくにClaude Code）をチーム開発に組み込むとき、CLAUDE.mdが「AIエージェントのための憲法・業務マニュアル」として機能します（Claude Code - GitHub Actions、Claude Code - GitLab CI/CD）。リポジトリのルートに配置し、ビルド・テストコマンド（npm test や ./gradlew build などプロジェクト固有のコマンド）、コーディング規約（命名規則、ディレクトリ構造、使用すべきライブラリ）、アーキテクチャ概要（システム全体の設計思想）を記述します。

推奨されるGitHub Actions / GitLab CI のワークフローは次のとおりです（Mastering the Vibe - Claude Code）。開発者がIssueやPull Requestで @claude とメンションしてタスクを依頼する（例：「このIssueのバグを修正して」）。**Plan（計画）**として、GitHub Actions 上で Opus 4.6 が起動し、リポジトリとIssueを読み込んで修正計画をコメントとして投稿する。人間が計画を確認し、OKなら実行を指示する。実装と検証では、エージェントがコードを修正し、CLAUDE.md に記載されたテストコマンドを実行し、テストが通るまで自律的に修正を繰り返す。PR作成では、修正が完了したらPull Requestを作成（または更新）し、人間の最終レビューを待つ、という流れです。

開発がこう変わる——サンプルコードで見る三つの変化

ここでは、従来の開発とOpus 4.6を前提にした開発の違いを、三つのサンプルコードで具体的に示します。各サンプルについて前提がそろっていれば稼働するかを文末で整理しているので、そのまま試すか・概念だけ参照するかの目安にしてください。APIを扱うサンプルでは Anthropic API の利用登録とAPIキー（環境変数で渡す想定）が必要です。

変化1：リポジトリに「AI用の設計書」を置く（CLAUDE.md）

従来は、ビルド手順やテストのやり方はREADMEやWikiに書いても、AIはそれを読んで動く前提になっていませんでした。Opus 4.6（Claude Code）では、リポジトリルートの CLAUDE.md を読んでビルド・テスト・規約に従います。開発者とAIの共通の「設計書」を置く、という変化です。

以下は、Node.js の小さなサービスを想定したCLAUDE.mdの最小例です。役割は、Claude がこのリポジトリで作業するときに「どのコマンドでビルド・テストするか」「どの規約に従うか」を一箇所で示すことです。各セクションの意味は次のとおりです。ビルド・テスト＝AI が依存インストール・テスト・リントを実行するときのコマンド。コーディング規約＝生成するコードの言語・配置・テストファイルの置き場所。アーキテクチャ＝サービス全体の役割とルーティングの場所の簡潔な説明。実際のプロジェクトでは、使用するパッケージ名やディレクトリ構造に合わせて書き換えてください。

# このプロジェクトで Claude が従うこと

## ビルド・テスト
- 依存インストール: `npm ci`
- テスト: `npm test`
- リント: `npm run lint`

## コーディング規約
- 言語: TypeScript。`src/` にソースを置く。
- テストは `*.test.ts` で `src/` と同階層に配置。

## アーキテクチャ
- このサービスは REST API を提供する。ルートは `src/routes/` で定義。

プロジェクトルートに CLAUDE.md を置き、Claude Code でそのリポジトリを開いてタスクを依頼すれば、ここに書いたコマンドでビルド・テスト・リントが実行されます。APIでリポジトリコンテキストにこのファイルを含めて呼び出す場合も同様です。

変化2：タスクに応じて「考える量」を指定する（API + effort）

従来は、簡単な変換も難しい調査も同じモデル・同じプロンプトで扱い、「どこまで考えさせるか」を細かく制御しづらかったです。Opus 4.6では effort を指定することで、単純なタスクは低コスト・低レイテンシ、複雑なタスクは深い推論に振り分けられます。アプリ側で「難易度判定→別モデルへルーティング」するロジックが不要になる、という変化です。

次のPython例は、タスクの難易度に応じて effort を切り替え、1つのモデルで「速く・安く」と「深く考える」を使い分けるプログラムです。ask_claude がプロンプトと effort を受け取り API を呼び、応答テキストを返します。APIキーは環境変数 ANTHROPIC_API_KEY に設定する想定で、キーそのものはコードに含めません。Opus 4.6 では effort は output_config 内で指定し、adaptive thinking は thinking: { type: "adaptive" } のみでよく、budget_tokens は非推奨です（Effort、Adaptive thinking）。

プログラムの流れ: ① ask_claude(prompt, effort) で API キーからクライアントを作成 ② messages.create でプロンプト・適応型思考・effort を送信 ③ 応答の content から「本文」の text ブロックだけを取り出して返す ④ 呼び出し側で、簡単なタスクは effort="low"、複雑なタスクは effort="high" を渡してコストと品質を切り替える。

# 前提: Python 3.8+, pip install anthropic 済み。環境変数 ANTHROPIC_API_KEY を設定すること。
# Opus 4.6 が利用可能なアカウントであること。
import os
from anthropic import Anthropic

def ask_claude(prompt: str, effort: str = "medium") -> str:
    """プロンプトと effort を渡し、Claude の応答本文（text）を返す。"""
    client = Anthropic(api_key=os.environ.get("ANTHROPIC_API_KEY"))
    response = client.messages.create(
        model="claude-opus-4-6",
        max_tokens=1024,
        thinking={"type": "adaptive"},   # タスクに応じて思考量を自動調整
        messages=[{"role": "user", "content": prompt}],
        output_config={"effort": effort},  # low=省コスト/速い, high=深く考える (Opus 4.6のみ)
    )
    # 応答は thinking ブロック＋text ブロックの順で返る場合がある。ユーザーに返すのは最後の text
    text_blocks = [b for b in response.content if getattr(b, "text", None)]
    return text_blocks[-1].text if text_blocks else ""

# 単純なタスク → effort を low にすると思考を抑え、低コスト・低レイテンシで即答
simple = ask_claude("次のログをJSONに整形して: ERROR 404 /api/users", effort="low")

# 複雑なタスク → effort を high にすると思考トークンを多く使い、推論してから回答
complex_task = ask_claude(
    "このスタックトレースから考えられる原因を3つ挙げ、それぞれの確認方法を短く書いて。\n"
    "[スタックトレース省略]",
    effort="high",
)

Python 3.8+ と anthropic パッケージ、環境変数 ANTHROPIC_API_KEY、および Opus 4.6 が利用可能なアカウントがそろっていれば、上記のまま実行できます。モデル名やパラメータは Messages API の最新仕様に合わせて変更される場合があるため、エラーが出る場合は公式ドキュメントで確認してください。

変化3：テスト結果をフィードバックにしたループ（Harnessの最小イメージ）

従来は「AIがコードを出す → 人間が手動でテストする」が多く、AIが自分でテスト結果を見て直すループは自前で組む必要がありました。Opus 4.6を「同僚」として使うときは、テストを実行し、失敗ならその結果を次のプロンプトに渡して修正させるHarness（足場）を用意すると、自律的に直しにいく動きに近づきます。

以下は、そのまま実行できる Bash Harness です。全体の役割は「npm test が失敗するあいだ、Claude に修正案を出させてファイルを上書きし、テストが通るまで繰り返す」ことです。ループは Bash、Claude API の呼び出しと「修正後のファイル内容」の取得は組み込みの Python で行い、取得した内容で対象ファイルを上書きしてから再度 npm test を実行します。修正対象は1ファイルに絞っています（複数ファイル対応は CI や Claude Code に任せる想定です）。

処理の流れ（1試行あたり）: ① 引数または環境変数で修正対象ファイルを決める ② npm test を実行し、成功なら終了 ③ 失敗したらテスト出力を一時ファイルに保存 ④ 組み込み Python で「現在のファイル内容」と「テスト失敗ログ」を Claude API に送り、「修正後のファイル全文」を得る ⑤ 応答からコードブロック用の記号を除いて対象ファイルを上書き ⑥ 最大5試行まで ② に戻る。

#!/bin/bash
# 前提: Python 3.8+, pip install anthropic, 環境変数 ANTHROPIC_API_KEY を設定すること。
# 使い方: ./harness.sh path/to/fixable_file.js  または  FILE_TO_FIX=src/index.js ./harness.sh
# プロジェクトルートで実行し、npm test が存在するプロジェクトであること。
set -e
MAX_ITERATIONS=5
# Claude への指示: 「テストが通るように修正し、応答はファイルの全文だけ返す」という意味
TASK="${TASK:-Fix the code so that npm test passes. Respond with ONLY the complete new file content, no explanation and no markdown code fence.}"
FILE_TO_FIX="${1:-${FILE_TO_FIX}}"
if [[ -z "$FILE_TO_FIX" || ! -f "$FILE_TO_FIX" ]]; then
  echo "Usage: ./harness.sh <path-to-file>  OR  FILE_TO_FIX=path ./harness.sh"
  exit 1
fi
# セキュリティ: 修正対象はカレントディレクトリ配下に限定する
ABS_ROOT=$(pwd)
ABS_FILE=$(cd "$(dirname "$FILE_TO_FIX")" 2>/dev/null && pwd)/$(basename "$FILE_TO_FIX")
if [[ "$ABS_FILE" != "$ABS_ROOT"/* ]]; then
  echo "Error: FILE_TO_FIX must be under the current directory ($ABS_ROOT)"
  exit 1
fi
TEST_OUTPUT_FILE=$(mktemp) || { echo "Error: mktemp failed"; exit 1; }
trap "rm -f '$TEST_OUTPUT_FILE'" EXIT
export TASK
for ((i=1; i<=MAX_ITERATIONS; i++)); do
  echo "=== 試行 $i / $MAX_ITERATIONS ==="
  # テストを実行。成功すれば終了
  if npm test 2>/dev/null; then
    echo "テスト成功。Harness 終了。"
    exit 0
  fi
  # 失敗時: テスト出力を一時ファイルに保存し、Python に渡して Claude から修正版を取得
  TEST_OUTPUT=$(npm test 2>&1) || true
  echo "$TEST_OUTPUT" > "$TEST_OUTPUT_FILE"
  NEW_CONTENT=$(python3 - "$FILE_TO_FIX" "$TEST_OUTPUT_FILE" <<'PY'

import os, sys
# 引数: 修正対象ファイルのパス、テスト出力を書き出した一時ファイルのパス
path, test_output_path = sys.argv[1], sys.argv[2]
api_key = os.environ.get("ANTHROPIC_API_KEY")
if not api_key:
  sys.exit(2)
task = os.environ.get("TASK", "Fix the code so npm test passes.")
content = open(path).read()
test_output = open(test_output_path).read()
# Claude に「現在のファイル」と「テスト失敗ログ」を送り、修正後の全文を得る
from anthropic import Anthropic
client = Anthropic(api_key=api_key)
resp = client.messages.create(
  model="claude-opus-4-6",
  max_tokens=8192,
  thinking={"type": "adaptive"},
  messages=[{"role": "user", "content": f"{task}\n\nCurrent file:\n```\n{content}\n```\n\nTest failure:\n```\n{test_output}\n```"}],
  output_config={"effort": "high"},
)
# 応答のうち、ユーザーに返す本文（text）だけを取り出す
text_blocks = [b for b in resp.content if getattr(b, "text", None)]
out = (text_blocks[-1].text if text_blocks else "").strip()
# 応答が ``` で囲まれている場合は外してから返す
if out.startswith("```"):
  lines = out.split("\n")
  if lines[0].strip().startswith("```"):
    lines = lines[1:]
  if lines and lines[-1].strip() == "```":
    lines = lines[:-1]
  out = "\n".join(lines)
print(out)
PY
)
  if [[ $? -eq 2 ]]; then
    echo "Error: ANTHROPIC_API_KEY が設定されていません。"
    exit 2
  fi
  if [[ -z "$NEW_CONTENT" ]]; then
    echo "API が空の応答を返しました。"
    exit 1
  fi
  # 取得した内容で対象ファイルを上書きし、次の試行で再度 npm test が走る
  echo "$NEW_CONTENT" > "$FILE_TO_FIX"
done
echo "最大試行回数に達しました。"
exit 1

次がそろっていれば、そのまま動きます。

環境: Bash、Python 3.8+、pip install anthropic 済み、環境変数 ANTHROPIC_API_KEY を設定済み、Opus 4.6 が利用可能なアカウント
プロジェクト: プロジェクトルートに package.json があり、npm test でテストが実行できること。修正対象は1ファイルで、そのパスを引数（または FILE_TO_FIX）で渡すこと
使い方: chmod +x harness.sh のあと、./harness.sh src/index.js のように実行。オプションで TASK="…" を指定するとプロンプトを上書きできます

注意点として、API コストとレート制限がかかります。試行回数 × 1リクエスト分のトークンが消費されるため、必要に応じて MAX_ITERATIONS を小さくするか、本番では GitHub Actions などでタイムアウト・権限を設定してください。Cコンパイラの事例で述べた「Oracle（GCC）の出力をフィードバックとして渡す」の、1ファイル版がこの Harness です。

サンプルコードのセキュリティ上の注意

本記事のサンプルを利用・改変する際は、次の点に注意してください。

API キー
API キーは環境変数で渡し、コードやログに含めないでください。本番では最小権限のキーを使い、漏洩時には無効化できるようにします。CI ではシークレット管理（GitHub Secrets 等）を使い、スクリプト内で echo しないようにしてください。

Harness（Bash スクリプト）

API の出力は未検証のコードです。モデルが意図せず有害なコードを返したり、プロンプトが改ざんされていたりする可能性があるため、取得した内容でファイルを上書きしたあとは必ず差分を確認し、コミット前に人間がレビューしてください。信頼できないリポジトリや未検証の入力でそのまま自動コミットしないでください。
修正対象のパスについて、記事中のスクリプトはすでに「カレントディレクトリ配下であること」を検証しており、../ でプロジェクト外を指定するとエラーで終了します。自前で Harness を組む場合も、書き込み前に同様のパス検証を入れると安全です。
一時ファイルは記事中のスクリプトでは mktemp を使っており、終了時に削除しています。他言語や自前実装で Harness を書く場合も、固定パスを避けユニークな一時ファイルを利用してください。
npm test はプロジェクトのコードを実行します。信頼できないリポジトリでは実行せず、可能なら隔離環境（コンテナや専用 runner）で動かしてください。

プロンプトと入力
ユーザー入力や外部データをそのままプロンプトに含めると、プロンプトインジェクション（意図しない指示の混入）のリスクがあります。Harness では「ファイル内容」と「テスト出力」を API に送っていますが、これらが攻撃者に制御可能な場合は、プロンプトの形を崩されないよう区切りやエスケープを検討し、必要なら入力をサニタイズしてください。

CLAUDE.md
CLAUDE.md は AI に読ませる設計書なので、機密情報（パスワード、内部URL、個人情報）は書かないでください。コンテキストに含まれると API に送信され、ログやキャッシュに残る可能性があります。

この三つ（CLAUDE.md でAIと設計を共有、effort で考える量を切り替え、テスト結果をフィードバックにしたループ）を組み合わせると、「何を作るか」と「正しさを確かめる仕組み」を人間が設計し、実装と修正の試行はOpus 4.6に回す、という開発の変化が具体的にイメージしやすくなります。

FinOps：コスト管理のベストプラクティス

Opus 4.6は高機能ですが、コストも高額になりがちです。とくにAdaptive Thinkingは「どれだけ考えるか」をAIが決めるため、コストが変動します（Laravel News - Claude Opus 4.6、Usage and Cost API）。

コスト構造の目安は、入力が $5.00 / 100万トークン、出力が $25.00 / 100万トークン、200kトークン超の入力は $10.00 / 100万トークン（プレミアム価格）です（Anthropic - Introducing Claude Opus 4.6）。

制御策として、次の三点が有効です（FinOps for AI）。第一に、Effortパラメータの使い分けです。重要でないバックグラウンドタスクや単純なデータ処理には effort: low を強制し、本番環境のデプロイ前チェックやセキュリティ監査には effort: max を許可する、といったポリシー管理が必要です。第二に、max_tokens のハードリミットをAPIリクエストごとに設けることで、意図しない無限ループや過剰な長文生成を防ぐことが推奨されます（Claude API - Adaptive thinking）。第三に、推論リージョンの管理です。データレジデンシー要件がない場合は安価なリージョンを選ぶ、逆にコンプライアンス要件がある場合は inference_geo パラメータで処理場所を固定（例：USのみ）する、という選択が可能です（コスト増の可能性はあります）。

まとめ——「何を作るか」と「正しさを確かめる仕組み」に集中する

冒頭で「三本柱→数値→現場にどう載せるか」までたどると約束したとおり、Agent Teams（チームで動く）、Adaptive Thinking（考え方の制御）、**100万トークンとCompaction（扱える情報量）**を軸に Opus 4.6 の「同僚」としての姿を見てきました。ベンチマークで効く根拠を押さえ、セキュリティと信頼性、そして CLAUDE.md や Harness で現場に載せる方法まで一通り触れました。ここで一度、要点をまとめます。

Claude Opus 4.6の登場は、IT技術者に対して「コーダー」から「アーキテクト」への進化を促しています。Cコンパイラの事例が示したように、Opus 4.6は「仕様」と「検証環境」さえあれば、実装の大部分を自律的に遂行できます。人間のエンジニアの仕事は、「どう書くか（How）」を考えることから、「何を作るか（What）」を定義し、「それが正しいか（Validation）」を確認する仕組みを作ることへシフトしていく、という意味合いがあります。

明日から取り組める三つのアクションとして、次のことが現実的です。第一に、検証環境（Harness）の整備です。AIが自走できるよう、テストカバレッジを高め、CIパイプラインを堅牢にします。第二に、CLAUDE.md の導入です。暗黙知となっていたプロジェクトのルールを明文化し、AIに読める形にします。第三に、セキュリティ監査への適用です。Opus 4.6の推論能力を活用し、既存コードベースの潜在的な脆弱性を洗い出します。

Opus 4.6はエンジニアを置き換えるものではなく、**能力を拡張する強力な「同僚」**です。この新しい同僚を使いこなすための環境を整えることこそが、これからのIT技術者に求められる最も重要なスキルになるでしょう。

付録：Opus 4.6 技術スペッククイックリファレンス

機能	スペック	技術的インパクト
コンテキストウィンドウ	1,000,000 トークン（Beta）	リポジトリ全体の読み込みが可能。大規模リファクタリングに必須。
出力上限	128,000 トークン	モジュール単位・ファイル単位での一括生成が可能。
推論エンジン	Adaptive Thinking	タスク難易度に応じて計算リソース（コスト）を自動調整。
制御パラメータ	Effort（Low / Medium / High / Max）	速度重視か品質重視かをAPIレベルで制御可能。
エージェント性能	65.4%（Terminal-Bench 2.0）	CLI操作・環境構築を含むタスクの自律遂行能力でSOTA。
検索精度	76%（MRCR v2 @ 1M）	大量データからの情報抽出における信頼性が飛躍的に向上。
コスト	$5（In）/ $25（Out）	高機能だが、思考トークン量による変動コストに注意が必要。

作成日: 2026年2月7日