Zenn
🕵️

Claude codeの手抜きを防ぎ、出力の質を上げるコツ：ロールベース開発

に公開
LLM
開発効率
プロンプトエンジニアリング
Claude Code
idea

はじめに

Aizackと申します。6月初旬からClaude codeのProプランに契約し、一ヶ月ほど生成AIを利用して学習しています。
もともとはClaude codeをPythonのコーディング教材として利用しようとしていました。
ところが、思ったように開発が進まなかったため「生成AIから良い出力を引き出す方法」を考え学ぶようになりました。

そうした悩みから、普段は以下のようなZennの記事やプロンプトエンジニアリングについてまとめています。
https://zenn.dev/deodeo/articles/94f0665825bdae
https://zack-k.github.io/gen_ai_report/

SNSで反響があった手法を記事化

思いつきで試した手法なのですが、ポストすると珍しく反響があったため、記事にまとめてみました。

提案手法：ロールベースレビューによる出力品質向上

以下のように、実際の開発フロー同様の職能レビューやPDCAサイクルを活かすことでLLMの特徴を活かした開発ができるようになる？という仮説です。

  • AIでコードを生成する際に、複数のロールで繰り返しレビューを行うように指示することで出力の質が向上する
  • 計画を立てた後に、他のロールでレビュー、それを受けて修正、承認がとれたら実装開始、というPDCAを行う

理論的背景：深津式プロンプトとLLM特性の活用

  1. いわゆる「深津式プロンプト」
    明確な役割設定と段階的な条件指定により、一貫性が高い文章を生成しやすくなるものです。note社の深津さんが広めたイメージがあります。
    普段からこの手法を使っていく中で、ロールを増やすとどのように出力が変化するのかを試してみたくなりました。
    複数のロールを入力として与えると、それぞれの視点で回答を出力するようになったため、プロンプトのテンプレート例 のような形に落ち着いています。

基本構造

標準テンプレート
#命令書:
あなたは{role}です。
以下の制約条件と入力文をもとに、最高の結果を出力してください。

#制約条件:
・{constraint_1}
・{constraint_2}
・{constraint_3}

#入力文:
{input_text}

#出力文:
  1. LLMの性質を知った
    LMMは次にくる単語の確率予測を行う

この性質を知り、以下のような疑問が湧いてきました。

  • プロンプト中でロール指定することでそのロール特有の単語出力確率を上げる効果があるのでは？
  • 現実世界の開発フローをAIの開発に導入したら上手くいくのでは？

それを色々なプロンプトで試すなかで、うまく出力できるようになったのが以下、プロンプトのテンプレート例 です。

実装例：段階別プロンプトテンプレート3パターン

以下に普段Claude codeに入力しているロールベースのプロンプトを3例お見せします。
役割を与えてあげることで、明確な行動を促しやすくなります。

  1. 要件の確認とTODOリスト作成
プロダクトマネージャーとしてプロジェクトドキュメントを参照して、
今後のTODOリストを生成してください。
  1. プロダクトマネージャーが作成した計画を基に設計と実装計画・TODOリストの作成
上記プランを基に、以下のロールで設計とTODOを作成してください。熟考してください。
  ・開発エンジニア
  ・QAエンジニア
  1. 実装時確認、複数ロールでのプロジェクトレビュー
現状のプロジェクトの抱える課題を以下のロールでレビューしてください
  ・開発エンジニア
  ・QAエンジニア
  ・プロジェクトマネージャー/プロダクトマネージャー

検証結果：ロール指定による出力内容の変化分析

  • 複数のロールでのレビューを入力したプロンプト
  • 上記プロンプトの結果として出力されたもの
    ロールの職責に近いキーワードが表示されており、具体的で目的が明確になっている

課題分析：従来手法の限界と問題点の整理

  1. 以下のような失敗経験
  • 単一ロールAIの限界と問題行動
    • 近視眼的に設計・実装を行ってしまうために、ヌケモレ・ダブりだらけのコードが量産されてしまう
  • テスト軽視と設計ショートカット
    • テストに失敗しているコードの修正を依頼したところ、実装の修正ではなくテストコードの削除の提案された
  • 「動けばいい」という最適化の罠
    • 開発のほどんどを手戻り修正に時間を取られ、トークン不足に陥る
  1. 最近見つけた記事からの引用として「報酬ハッキング問題」
  • 以下の参考資料ではLLMが報酬ハッキングを行い、人間を騙してしまうことが指摘されています。
    • 正確には、Anthropic などのグループが行った Language Models Learn to Mislead Humans via RLHF（言語モデルは RLHF を通じて人間を誤解させることを学ぶ）という発表に関して、筆者が要点整理したものです。
- この研究では、極端な解を避ける機構を持つ真っ当な RLHF を用いて、
むしろ報酬ハッキングを避けようとすらしたにもかかわらず、
LLM が人間を騙すような振る舞いをすることを観察した

- この研究では人間の評価をより直接的に使ってもなお LLM は報酬ハッキングをし、
しかもその出力を人間が見ても設計ミスに気付けず、
むしろ人間は知らず知らずのうちに騙されてしまう現象を観察した

- 質問応答とコーディングタスクの実験により、
例えば LLM は解けなかった問題に対してダーティーなコードを出力して間違いを隠蔽する、
といった人間のプログラマを騙すような具体的な手口を特定した

実践ガイド：2フェーズのロールベース開発フロー

各ロールの責任と視点

プロジェクトマネージャー

  • ビジネス要件の充足確認
  • スコープとリソースの妥当性
  • リスクの洗い出しと対策

開発エンジニア

  • 技術的実現可能性
  • アーキテクチャの妥当性
  • コードの保守性・拡張性

QAエンジニア

  • テスト観点の網羅性
  • エッジケースの考慮
  • 品質基準の達成度

フェーズ1: 要件定義・設計

  1. プロジェクトマネージャーとして要件定義
  2. 開発エンジニアとして設計
  3. 3ロールで設計レビュー
    • プロジェクトマネージャー視点
    • QAエンジニア視点
    • 開発エンジニア視点
  4. 承認判定
    • 承認 → フェーズ2へ
    • 非承認 → ステップ5へ
  5. 開発エンジニアとして設計修正 → ステップ3に戻る

フェーズ2: 実装・品質検証

  1. 開発エンジニアとして実装開始
  2. QAエンジニアとしてレビューと品質検証
  3. 開発エンジニアとして修正
  4. 3ロールで最終レビュー
    • プロジェクトマネージャー視点
    • QAエンジニア視点
    • 開発エンジニア視点
  5. 最終承認判定
    • 承認 → 完了
    • 非承認 → ステップ8に戻る

開発フロー図

上記の要件定義・設計〜実装・品質検証を図示すると以下のようになります。

まとめ：手法の有効性と今後の展望

ロールベース開発手法は、LLMの確率論的特性を活かした実用的なアプローチだと考えています。

この手法の価値

  • AI特有の「楽な方向への逃避」を防ぐ
  • 複数視点による品質向上
  • 開発効率とコード品質の両立

すぐに始められること

  1. 開発者とQAの2ロールから開始
  2. 小さなタスクで効果を確認
  3. 段階的にロールとプロセスを拡張

皆さんもぜひ試してみて、効果や改善点をコミュニティで共有していただければと思います。

参考資料：追加プロンプトテンプレート集

  • Claude Codeロールベース開発プロンプトテンプレート集
    記事を作成する際のメモやレビュー内容をもとに、生成AIにプロンプトのテンプレートを作ってもらいました。試用版です。これから私も使ってみますが、もしご興味があれば使ってみて感想を教えて下さい。

https://claude.ai/public/artifacts/7f239463-4a47-4927-b72d-11404571fd6e

Discussion