Notes — 研究ノート
自分のOSSを
複数のAIにレビューさせたら
何が起きたか.
Claude Opus 5 と GPT-5.6 Sol に、同じドキュメントを独立にレビューさせ、
結果を突き合わせた。一致した指摘は信頼し、食い違いは精査した。
What We Did
何をしたか。
prompt-as-code は、LLMプロンプトをコードとして扱うための構文標準（RFC形式）です。2025年12月に公開し、v0.3.0 まで育ててきました。
2026年8月、コンテキストエンジニアリングへのポジショニング更新に合わせて v0.4.0 へのメジャーアップデートを行うことにしました。しかし、1,100行のドキュメントを一人で精査するのは現実的ではありません。
そこで、異なるAIモデルに同じドキュメントを独立にレビューさせ、結果を突き合わせるというアプローチを取りました。
Method
検証の設計。
検証は2段階で行いました。
| Phase 1 パターン有効性の検証 | SCoT（構造化思考連鎖）、Few-shot、CoVe（検証連鎖）の3パターンについて、同一のテストプロンプトを Opus 5 と GPT-5.6 Sol の両方に実行させ、パターンが2026年のモデルでも有効かを確認しました。 |
|---|---|
| Phase 2 ドキュメント全体の監査 | STANDARDS.md の全文を両モデルに読ませ、「事実誤り」「不足トピック」「不要な記述」「技術的に誤った主張」を独立に指摘させました。互いの出力は見せていません。 |
重要なのは、2つのモデルが互いの出力を知らないことです。独立したレビュアーの意見が一致すれば信頼度は高く、食い違えば精査が必要——人間のコードレビューと同じ原理です。
Phase 1 Results
パターンは、まだ効くのか。
結論から言えば、3パターンとも両モデルで有効性が確認されました。
| SCoT XML タグで思考と結論を分離 |
両モデルとも <thinking> / <answer> タグに準拠。指示がなければ「Markdown ヘッダーを使う」「自由形式にする」と回答——つまり、明示的な指示がなければモデルはこの構造をデフォルトにしません。パターンに意味があります。
|
|---|---|
| Few-shot 例示による出力フォーマット制御 | 両モデルとも例示されたフォーマットに正確に準拠。「例がなければ同じ形式にはしない」と明言。2026年のモデルでも、出力形式の制御には例示が有効です。 |
| CoVe 自己検証ループ | 両モデルとも C1〜C4 のループ構造に従い、自分のドラフトの約40%の事実主張を自己修正しました。さらに面白いことに、修正箇所が両モデルで異なっていました。 |
CoVeの結果は特に示唆的です。同じ質問に対して、Opus 5 は「Micronaut 4 のリリース日」と「Blazor United の命名」を修正し、GPT-5.6 Sol は「React のライブラリ/フレームワーク分類」と「GitHubランキング手法の曖昧さ」を修正しました。同じパターンが、異なるモデルの異なる盲点を補正している——これはパターン自体の汎用性を示す良い証拠です。
Phase 2 Results
何が見つかったか。
ドキュメント全体の監査では、両モデルが一致した指摘と、片方だけが見つけた指摘がありました。
両モデルが一致した指摘（信頼度：高）
| CO-STAR「ゴールドスタンダード」 | 「業界標準」という記述は過大表現。実際は「広く採用されているフレームワーク」が正確。なお帰属については、Opus 5 が「GovTech開発ではなくSheila Teoが発表」と指摘しましたが、ファクトチェックの結果、GovTechのチームが開発しSheila Teoがコンペで活用・解説して広めたのが正確でした——AIのレビュー結果自体もファクトチェックが必要という教訓です。 |
|---|---|
| CoVe / CoD の表現 | 「標準になりつつある」「リファレンススタンダード」は、いずれも研究テクニックに対する過大表現。「推奨手法」「有効な手法」に修正。 |
| extended thinking の混同 |
プロンプト内の <thinking> タグ（出力構造化のテクニック）と、ClaudeやOpenAI o-seriesのAPIレベルのextended thinking（モデル機能）が区別されていない。
|
| セキュリティの不足 | 直接的なプロンプトインジェクションのみカバーし、RAGやツール出力経由の間接インジェクションに言及がない。 |
片方だけが見つけた指摘（精査が必要）
Opus 5 は構造的な問題を多く指摘しました（目次の不備、セクション配置、モデルリストの不整合）。一方 GPT-5.6 Sol は技術的な正確性に踏み込み、triple-backtick のMarkdownネスト問題、RAGコード例のバグ、SemVer 0.y.z の説明不正確などを指摘しました。
興味深いのは、GPT-5.6 Sol が「"State everything explicitly" は agentic models の時代に過度ではないか」と指摘したことです。エージェントが自律的に動くなら、プロンプトは簡潔な目標と制約だけを示す方が良いという主張——これはドキュメントの根底にある哲学への問いかけであり、単純に「正しい/間違い」とは言えません。
Human Judgment
人間が判断したこと。
AIのレビュー結果を全て鵜呑みにしたわけではありません。両モデルとも「このドキュメントに足りないトピック」を大量に挙げましたが、その多くはドキュメントのスコープ外でした。
prompt-as-code は「プロンプトとして書くテキストの構文仕様」です。Markdownで書ける範囲が境界線です。
| AIが「足りない」と指摘 | 人間の判断 |
|---|---|
| Structured Output / JSON mode | APIパラメータ。構文仕様のスコープ外。 |
| Tool definitions / Function calling | API機能。スコープ外。 |
| マルチモーダルプロンプティング | テキスト構文仕様の範囲外。 |
| Prompt caching | インフラ層。スコープ外。 |
| Persistent context files | 別トピック。 |
AIは「あれもこれも足りない」と網を広く投げます。しかし、ドキュメントのスコープを決めるのは人間の仕事です。スコープ判断の結果、足りなかったのはトピックではなく、「このドキュメントが何を扱い、何を扱わないか」のスコープ宣言だったことがわかりました。
Result
最終的に何を変えたか。
検証結果を受けて、v0.4.0 では以下を修正しました。
- 事実誤り 5 件の修正（CO-STAR帰属、過大表現3件、翻訳テンプレートのバージョン）
- 技術的正確性の向上 6 件（extended thinkingの区別、間接インジェクション、コード例のバグ修正等）
- [Step N] 記法の根拠書き換え（「モデルがパースに失敗する」→「タスク分割・HITL・出力参照のための構造化」）
- 構造改善（目次の完成、陳腐化した「NEW」マーカーの除去）
- README.md と CONTRIBUTING.md の同期更新
全修正は GitHub リポジトリで確認できます。検証結果の生データも test-results-v040-*.md として同梱しています。
Takeaway
この方法が教えてくれること。
このアプローチから得られた知見は3つあります。
第一に、独立したモデルの一致は、単一モデルの確信より信頼できます。CO-STARの帰属誤りは、Opus 5 だけなら「そうかもしれないし、そうでないかもしれない」で終わっていたかもしれません。2つのモデルが独立に同じ指摘をしたから、修正に踏み切れました。
第二に、モデルごとに視点が違います。Opus 5 は構造的・俯瞰的なレビューが得意で、GPT-5.6 Sol はコード例のバグや技術定義の正確性に強かった。どちらかだけでは見落としが出ます。
第三に、スコープ判断は人間にしかできません。AIは網を広く投げるのが得意ですが、「何を入れないか」を決めるのは、ドキュメントの目的と読者を知っている人間の仕事です。
これは前回の記事で書いた「デザインタイムのコンテキストエンジニアリング」の実践例でもあります。AIに何をレビューさせ、その結果をどう判断するか——それ自体がコンテキストの設計です。