Codex on Feature Branch Tech Blog

テスト工程におけるAI活用

Thu, 18 Jun 2026 00:00:00 +0900

1. はじめに

テスト項目の作成では、Jira、仕様書、ソースコードを見ながら「何を、どの条件で、どう確認するか」を具体化します。

この作業に、最初からAIを使っています。ただし、Codexへ直接依頼し続けるとコンテキストを多く使い、5時間単位や1週間単位の利用制限も気になります。

そこで、まずChatGPTで依頼文を整理し、その内容をCodexに渡してテスト項目のたたき台を作っています。

2. テスト工程をざっくり整理

テスト工程は、確認する範囲で分けると理解しやすいです。 ISTQBでも、テストレベルは目的や責任範囲に応じて整理されています¹。

工程	何を見るか	担当イメージ
単体テスト	関数、入力チェック、画面部品など	実装者が中心
結合テスト	画面、API、DB、権限などのつながり	テストチームが中心
総合テスト	利用者の業務フロー全体	テストチームが中心

今回の主役は、結合テストです。

結合テストでは、単体では問題なさそうに見える部品を組み合わせたときに、正しく動くかを確認します。たとえば、画面で入力した内容が保存されるか、権限ごとに表示が変わるか、同時操作でデータが壊れないか、といった観点です。

3. 今回のテストチームの役割

今回のプロジェクトでは、役割を次のように分けています。

担当	主な作業
各実装者	単体テストを実施
テストチーム	結合テスト、総合テストを実施
テストチーム	パターンが多い単体テストも一部対応

テスト項目を作る材料は、主に以下です。

Jira
仕様書
ソースコード
操作マニュアル
既存のテスト項目

テスト項目では、「動作確認する」だけでは足りません。実施者が迷わないように、操作者、前提条件、操作手順、期待結果まで書く必要があります。

4. AIを使ったテスト項目作成の流れ

実際の流れはシンプルです。

手順	やること	担当
1	実装内容と確認したい観点をざっくり書く	人間
2	ChatGPTでCodex向けの依頼文に整える	ChatGPT
3	Jira、仕様書、ソースコードを見て項目を作る	Codex
4	内容を確認し、実施できる形に直す	人間

ChatGPTを挟む理由は、Codexを節約したいからです。

Codexにはソースコードを読んでほしいので、雑な相談や依頼文の整理でコンテキストを消費するのはもったいないです。そのため、ChatGPTで「Codexに何を頼むか」を先に固めます。

依頼文で指定する内容は、だいたいこのあたりです。

指定すること	例
参照元	Jira、仕様書、関連ソースコード
出力形式	Markdown表、CSVなど
試験分類	IT、ST
観点	正常系、異常系、権限、境界値、既存影響
追加情報	想定工数、不明点、確認が必要な点

OpenAIのプロンプトガイドでも、役割や必要な情報を明確にすることが有効だとされています²。テスト項目作成でも、依頼が具体的なほど出力が安定します。

2ターン設計で精度を上げる：VSCode×Codexのやりとり術

Thu, 22 Jan 2026 10:00:00 +0900

はじめに

「VSCodeからCodexにお願いしたけど、意図とズレた」――そんな経験はありませんか。私自身、短く書くと精度が落ち、長く書くと伝える内容が散らばることがありました。

そこで効果があったのが2ターン設計です。1回目で前提を確認し、2回目で実行に移す。たったそれだけで、精度と納得感が上がりました。この記事では、VSCode×Codexで使える「2ターンの型」を整理します。

1. なぜ1回でうまくいかないのか

LLMは文脈が不足していると、良い推測はしても本当に欲しい答えに辿り着けないことがあります。公式のプロンプト指針でも「目的・制約・期待する出力」を明確に伝えることが推奨されています¹²。

つまり、1回目の指示で「必要な前提が足りているか」を確かめるだけで、2回目の成功率が大きく上がります。

2. 2ターン設計の全体像

2ターン設計は、**確認（Turn 1）→実行（Turn 2）**の流れです。会話の段階を明確にするだけで、やりとりが安定します。

flowchart LR
 A[Turn 1: 調査・前提確認] --> B[Turn 2: 実装・反映]

Turn 1: 調査・前提確認

このターンでは、**「何を、どこまで、どういう形で」**を固めます。足りない情報があれば質問してもらい、必要な前提を揃えるのが目的です。質問してから進めるスタイルは公式例でも推奨されています³。

Turn 2: 実装・反映

Turn 1で前提が揃ったら、実装・修正・整理などを依頼します。ここでは作業のゴールと受け入れ条件が明確になっていることが大事です。

3. Turn 1のテンプレ（そのまま使える）

短くてもよいので、次の項目を伝えると迷いが減ります。

目的
変更範囲
期待する出力
制約（触らない場所、守るルール）
参照してほしいファイル

実際のテンプレはこんな感じです。

1
2
3
4
5
6
7


目的: 画面の表示崩れを直したい
変更範囲: @src/pages/order-detail/ だけ
期待出力: レイアウトが崩れずに表示されること
制約: UIの文言は変更しない
参照: @src/pages/order-detail/index.tsx

まず原因を調査して、必要なら質問してください。

ポイントは「まず調査して」と先にフェーズを指定することです。これだけで、いきなり修正を始めるリスクが減ります。

4. Turn 2のテンプレ（承認してから実行）

Turn 2では「OK、やってください」を明示します。明確な実行依頼が推奨されることは公式のベストプラクティスでも触れられています¹²。

1
2
3
4
5


ありがとうございます。修正案で進めてください。

- 変更は最小限で
- テストは不要
- 差分を最後にまとめてください

この形式だと、実装範囲が安定し、仕上がりの確認も楽になります。

頭脳 vs 手足：Claude Code（Opus 4.5）とCodex CLI（GPT-5.2）徹底比較

Tue, 06 Jan 2026 12:00:00 +0900

はじめに

2025年末から2026年にかけて、AIコーディングツールは新たなステージに突入しました。AnthropicのClaude Code（Opus 4.5）とOpenAIのCodex CLI（GPT-5.2）は、どちらも「AIエージェントが自律的にコードを書く」時代を切り開いています。

しかし、この2つのツールは設計思想が根本的に異なります。本記事では、**「頭脳 vs 手足」**という独自の視点からこの2大ツールを比較し、それぞれの強みと使い分けのポイントを解説します。

1. 両ツールの概要

まずは、それぞれのツールの基本的な特徴を押さえておきましょう。

1.1 Claude Code + Opus 4.5

Claude Codeは、Anthropicが提供するAIコーディングエージェントです。2025年11月にリリースされたOpus 4.5モデルと組み合わせることで、「世界最高のAIコーディングツール」を謳っています¹。

主な特徴は以下の通りです。

ローカルファースト設計: ターミナルやIDEに直接統合され、開発者のワークフローに溶け込む
インタラクティブな操作: 開発者が「コントロールを握り続ける」設計思想
チェックポイント機能: 作業の進捗を保存し、いつでも以前の状態にロールバック可能
ハイブリッド推論: 即座の応答と拡張思考を状況に応じて切り替え

1.2 Codex CLI + GPT-5.2

Codex CLIは、OpenAIが提供するオープンソースのAIコーディングエージェントです。GPT-5.2-Codexは、複雑なソフトウェアエンジニアリングタスクに最適化された専用モデルで、2025年12月にリリースされました²。

主な特徴は以下の通りです。

クラウドベース設計: タスクは隔離されたサンドボックス環境で非同期に処理
委任型ワークフロー: タスクを渡して「任せる」スタイル
長時間自律作業: テスト中に7時間以上連続して複雑なタスクに取り組んだ実績
サイバーセキュリティ強化: CTFチャレンジでの高精度を実証

2. 「頭脳 vs 手足」の比較軸

ここで本記事の核心となる比較軸を紹介します。

観点	GPT-5.2 Codex（頭脳型）	Claude Code + Opus 4.5（手足型）
設計思想	「深く考える」ことに最適化	「精密に実行する」ことに最適化
強み	巨大なコンテキスト、長時間思考	ローカル統合、ツール操作の精度
操作感	「従業員に任せる」感覚	「道具を使いこなす」感覚

2.1 GPT-5.2 Codex：「賢い頭脳」

GPT-5.2 Codexは、まさに**「頭脳派」**のAIエージェントです。