Agentが話すプロジェクト開発言語を多言語化する - 開発と仕様とテストとetc
Agentが話すプロジェクト開発言語を多言語化する
課題発見と実装修正を並行実行するClaude Code活用術 の続編です。
（完全自動化された Agentic Coding を、Claude CodeなどCLIツールで実現したい方向けの内容になっています。Vibeコーディングのように、CLIに向かって指示を打ち込む作業はほとんど必要ありません。）
開発、仕様、テストなど、Sub-Agentを分けるような単位で指示言語を分けてみます。
前回は同じ C3L/Climpt の climpt-* 言語のなかで分けていたのですが、今回は prefix から完全分離を行いました。
同じプロジェクト内部で、コーディング担当はコーディング用の指示で自動化し、ドキュメント化にはドキュメント用の指示で自動化します。
Agent言語が異なるので、Sub-Agent設定は不要ですが、Sub-Agentと言語を組み合わせてもよいでしょう。
ただ、Claude Codeが必ずSub-Agentを使うとは限らないため、大元の settings.json で分ける方が確実だと考えています。
役割を分ける
| 担当 | 作業概要 | 実行頻度 | 言語体系 |
|---|---|---|---|
| コーディング | GitHub Issueから最新Issueを用いて、優先度高い対応を実施。完了条件に行ったらClose。 | 連続稼働。IssueとPRがなくなるまで実施。 | コーディングサイクル |
| 仕様検証 | 要求要件および仕様を正とし、実装を検証。課題をGitHub Issueへ登録する。 | 30分から60分間隔で定期実行 | 仕様に基づくデバッグと検査 |
| ad-hoc | 単体作業の投入 | 発生時点 | 通常 |
コーディング担当のAgentは、コーディングのC3L/Climptしか話さないようにしています。
同様に、仕様検証担当のAgentは、仕様検証のC3L/Climptしか話さないようにしています。
言語を分ける
C3L/Climpt を用いて、 climpt-* をコードと通常利用の言語Prefixとし、 inspector-* を仕様検証の言語Prefixとしました。
C3L/Climpt, C3L/Inspectorのように定義を増やすことも可能ですが、今回はprefixのみを変更しています。前回は同じ climpt-* prefixのなかで、使う言語を分けていました。今回はさらに、Prefixを分けることで完全分離を行う試みです。
たとえば、以下の言語を定義し、仕様検証でのみ用いられるようにしました。
この inspector-* 言語は、コーディング担当には知られていないため、コーディング担当者が誤用することはありません。（実行の仕方も知りません）
inspector-debug trace-error cause-analysis → エラーデバッグ
inspector-debug plan-logger debug-strategy → ログ戦略構築
inspector-debug design-flow reproducible-steps → 再現性確保
言語を分けて実行した結果
よくチェックする作業自体をワークフローとしてメンテナンスさせてみました。
すると、例えば以下のように虚偽完了報告を確認するワークフローを構築してくれました。
この「False Resolution Detection Workflow」ワークフローを作る指示を具体的に出したわけではありません。
繰り返し発生する作業をワークフロー化し、メンテナンスする指示を与えています。
虚偽完了報告を確認するワークフロー:
# False Resolution Detection Workflow
## Overview
虚偽解決問題（コミットやIssue解決主張が実際の状況と一致しない問題）を検出・防止するためのワークフロー。
## 問題の背景
### 発生パターン
- コミットメッセージで「完全解決」を主張するが実際は問題継続
- Issue を「解決済み」でクローズするが根本原因未解決
- CI/CD 成功報告と実際の状況の乖離
:
自力解決できない問題が継続する際、多くは仕様上の不備が存在するものです。
曖昧さといえば単純ですが、データ構造と処理定義の＆条件のなかで、処理できないパターンに陥った場合に起こる混乱です。
こうした場合、仕様の更新を行う必要が生じるため、問題の挙げ方にも工夫を入れた指示を作っておくのが望ましいと考えています。
同一プロジェクト内での役割共存
同じソースコード、同じ仕様書をみて、同じGitHub Issueを触ります。
全く異なる視点と指示系統によって、直線的なClaude CodeのAgenticな動きとは異なる開発ができます。
コーディング視点で気づかない点を、要求や仕様視点で見つけにいきます。
これが役割と言語定義を完全分離しておくメリットです。
通常の開発プロセスのなかで、Sub-Agentへ役割分担することと似ていますが、根本的に違うのは、お互いがメインのAgentだということです。
そのため、MCPはじめ、各々が同じプロジェクトコードから異なるコンテキストを引き出し維持できる点に、違いがあります。
例: MCPや設定の区別
例えば仕様のレビューだけCodexに任せることを考えてみます。
Codex は仕様検討時にMCP経由で用います。
コーディング担当者では用いません。
Sub-Agentではなく、claude を立ち上げる時点で区別します。
具体的には、 settings.json と settings-docs.json で設定を変えておきます。
"enabledMcpjsonServers": ["climpt", "serena"],
"disabledMcpjsonServers": ["codex"],
や
"enableAllProjectMcpServers": true,
"enabledMcpjsonServers": ["climpt", "serena", "codex"],
"permissions": {
"allow": ["Climpt__*", "Serena_", "Codex_"]
},
のように設定します。
結果、以下のような表示になります。
│ Manage MCP servers │
│ │
│ ❯ 1. climpt ✔ connected · Enter to view details │
│ 2. serena ✔ connected · Enter to view details │
│ │
と
│ Manage MCP servers │
│ │
│ ❯ 1. climpt ✔ connected · Enter to view details │
│ 2. codex ✔ connected · Enter to view details │
│ 3. serena ✔ connected · Enter to view details │
│ │
補足: Codex を Claude Code からMCP利用する設定
Codex CLI を使える環境で、Claude Codeの .mcp.json へ記載します。
"codex": {
"type": "stdio",
"command": "codex",
"args": ["mcp"]
}
多言語化した効果
Codexは一例です。
以上のように、設定環境から変えておくことで、異なるAgentが立ち上げられます。
そもそも同じ言語を話す場合は、2つ異なる設定にするメリットはありません。
今回の設定に意味があるのは、同一プロジェクト内でAgentごとに役割を分け、共存・並列稼働させる点にあります。
分けた結果、RAGやタスク処理のベースになっている情報源も、変わります。
例えばコーディング担当者は GitHub Issue から作業を開始しますが、
仕様検証の担当者はドキュメントからスタートし GitHub Issue を作成・更新することが完了作業になります。
お互いの役割が完全分離されるため、コンテキストが混ざったりもせず、非常に効率がよくなると感じています。
特にコーディング担当者にとっては、対処すべき課題が明確な状態で実施できるため、問題調査によるノイズが入りにくくなります。
仕様検証の担当者も、十分深く実装を調査できるため、指摘がクリティカルになります。
Discussion