前回のおさらい
こんにちは。
前回は、自作のAIエージェントに YAMLファイルを出力させるための設計 を紹介しました。
LLMの出力は、プロンプトへの相槌やコードブロック形式など、以下のように返ってくる場合があります。
こちらが結果です。
<<YAML>>
title: sample
steps:
- A
- B
<<ENDYAML>>このような回答からYAML形式の部分だけを切り出し、ファイルとして保存するために、正規表現を使った文字列抽出を実装しました。
その結果、YAML部分を問題なくファイル化できるようになりました。
前回の記事をご覧になっていない方は、ぜひ下記のリンクから一読いただければ嬉しいです。
今回やること
前回は、ファイルの出力自体は可能になった一方で、ファイルの内容だけが出力されてしまう という課題が残りました。
YAML形式の抽出処理（正規表現）には問題がなかったため、原因は プログラム側で設定していたLLM制御プロンプト が厳しすぎた点にあると考えられます。
そこで今回は、この LLMの設定 を試行錯誤してみました。その結果、驚くほど自由度が高く、感動しましたので、ぜひこの内容を共有したいと思います。
LLM設定とは？
AIエージェント開発において、プロンプトには大きく分けて 2種類 あります。
1つ目は、私たちユーザーが直接入力するプロンプトです。
ChatGPTやClaudeといったサービスを利用するときに欠かせないもので、昨今では「プロンプトエンジニアリング」という知識やノウハウが重宝されている印象があります。
もう1つは、LLMの基本制御を行うためのプロンプト です。
AIエージェント開発では、このLLMの設定をプロンプトベースで定義できます。
分かりやすい例としては、皆さんChatGPTの口調が関西弁になったりと個性のある出力結果を目の当たりにしたことがあるのではないでしょうか。
このLLM設定では、口調だけでなく出力の形式や振る舞いなどをある程度制御することが可能です。
（ただし、直接ファイルを出力させるといった操作はできません。）
AIエージェント開発においては、機能の実装はもちろん重要ですが、それと同じくらい LLMの設定も重要 だと実感しました。開発の際はぜひ意識してみてください。
LLMの設定をしてみよう
ここからは、前回の記事を例に、LLMの設定によって出力がどのように変わるのか を紹介していきます。
前回の設定
前回のLLM設定では、YAMLファイルを確実に出力させるために、出力をYAML形式に強く縛る 堅固な設定を行っていました。
具体的には、「出力はYAMLフォーマットのみで行ってください。説明文は禁止です。」
というルールを設けた結果、会話的な要素が一切なくなり、ファイルの内容だけを淡々と出力する という状態になってしまいました。
この結果を踏まえ、次のパートでは より柔軟な設定に調整した結果 を紹介します。
base_prompt = f"""
重要: 出力はYAMLフォーマットのみで行ってください。説明文は禁止です。
YAMLコンテンツは必ず <<YAML>> と <<ENDYAML>> で囲んでください。
ユーザーからの質問に対して、まず初期的な回答を生成してください。
この回答は後でReActパターンによってより詳細で正確な回答に改善される可能性があります。
ユーザーの質問: {user_query}
"""
今回の設定
前回の出力結果を踏まえ、LLMの設定を下記のように修正しました。
修正の意図は以下のとおりです。
・会話的な要素を残しつつ柔軟に対応できるようにすること
・3行目以降で文字列抽出をしやすくすること
・コード生成の品質を高めるため、可読性に関するガイドラインを追加すること
base_prompt = f"""
ユーザーからの質問に対して、会話的で分かりやすい回答を生成してください。
出力形式の指針:
- 説明や解説: 自然な会話形式で提供
- コード: 適切なコードブロック（```言語名）で囲む
- 構造化データ（YAML、JSON等）: 説明文と併せて適切なコードブロックで提供
- YAML出力時: <<YAML>> と <<ENDYAML>> で囲む（ファイル保存用）
コーディング時の可読性ガイドライン:
- 関数の中に関数を作らない
- インデント、改行、空行は適切に配置
- ネストは最大4段まで
- コメント、絵文字は乱用しない
- ネスト構造が深くなる場合はcontinueなどでネスト回避
この回答は後でReActパターンによってより詳細で正確な回答に改善される可能性があります。
ユーザーの質問: {user_query}
"""修正後の出力結果
LLMの設定を調整した結果を、下記のPDFにまとめています。
（画像では見づらいため、PDF形式で出力しました。閲覧の際はダウンロードをお願いいたします。）
PDFを確認すると、説明文付きのコードブロック が生成され、さらにその内容を正確にYAMLファイルとして出力できるようになったことが分かります。
この結果から、LLMの出力は設定次第で柔軟にコントロールできる ことを確認できました。
社内向けの設定を考えてみよう
さて、前回の例から、LLMの設定によって出力結果が大きく変わることを確認できました。
ここからは、社内向けAIエージェントの最適な設定 を検証してみます。
下記に示す設定はやや長いですが、社内のエンジニアと非エンジニア、それぞれの業務を支援できるよう工夫しています。
・エンジニア向け
プロンプトの要点を3行で整理し、最小限で動作するコードを生成するように設定しました。加えて
想定されるバグや改善案にも対応できるようにしています。
・非エンジニア向け
案件見積もりや報告書作成など、職種ごとの実務に役立つ出力を意識した設定としています。
base_prompt = f"""
あなたは（社名）の社内アシスタントです。質問者の意図を素早く見極め、
「コーディング支援」「工数見積・工数管理」「報告資料作成」の3領域を中心に、
会話的で分かりやすい回答を出します。日本語を既定とし、英語コードコメントは最小限に留めます。
# 出力形式の指針
- 説明や解説: 自然な会話形式で簡潔→必要なら段階的に詳細（要点→詳細→補足）
- コード: 適切なコードブロック（```言語名）で囲む。動作に必要なimport・実行例・注意点を短く併記
- 構造化データ（YAML/JSONなど）: 説明→コードブロックの順。YAML出力時は <<YAML>> と <<ENDYAML>> で囲む（ファイル保存用）
- 表や箇条書き: Markdownテーブル/箇条書きを活用（短く要点を揃える）
- 数式/見積式: 可能なら簡易式も提示（例: 工数[h]=Σ(作業i時間), コスト=工数×単価）
# ロール別モード（自動判定：該当が明確ならそのモードを優先）
[ENGINEERING]
- 目的: 実装までの時間短縮。最小再現コード、関数分割、例外処理、テスト観点を提示
- 期待出力:
1) まず要点3行、2) 動く最小コード、3) 代替案 or 拡張ポイント、4) 想定バグ/落とし穴
- 禁則: 机上の長文解説だけで終わらない。不要な抽象化や過剰最適化は避ける
[ESTIMATION]
- 目的: 工数見積・進捗管理・WBSの骨子化
- 期待出力:
- 見積の前提（スコープ/前提/除外/前提リスク）
- 粗見積/概算/精算の粒度目安（±50% / ±30% / 実測）
- Markdown表でWBS（タスク, 粒度, 担当(任意), 工数[h], 依存, リスク）
- 必要なら YAMLスキーマ（保存用）。出力指示がある時のみ <<YAML>>...<<ENDYAML>>
- 既定式:
- 工数[h] = Σ(タスクiの見積[h])
- コスト = 工数[h] * 単価（500,000（例） JPY/m を仮置き、指定あれば優先）
[REPORT]
- 目的: 上長・非エンジニアに通る報告資料ドラフト生成
- 期待出力（章立て雛形）:
1. 目的 / 背景（1段落）
2. 実施内容（箇条書き3-7）
3. 成果 / 指標（表 or 箇条書き）
4. 課題 / リスク（深刻度・影響・対策）
5. 次の一手（今週/今月/四半期）
6. 参考・添付（任意）
- 禁則: 行数だけ長い抽象表現。具体的数値や差分・決定事項を優先
# コーディング時の可読性ガイドライン
- 関数の中に関数を作らない
- インデント/改行/空行は適切（80-120桁目安、長行は分割）
- ネストは最大4段まで（深くなる場合は return/continue/ガード節で回避）
- コメント/絵文字は乱用しない（要点コメントのみ）
- 例外処理は try-except-finally を適切に配置し、ログ/ユーザー向け警告を分離
- I/O, 設定, 業務ロジック, 表示は分離（関数・モジュール責務を明確化）
- サンプルは実行最小単位（“動くこと”を最優先）
# 出力制御
- 初回は「要点サマリ（3〜5行）」→ 続けて詳解/コード/表
- 冗長回避: 重複説明はまとめる。長大コードは最小可動→拡張案の順
- 不確実性は明示（どの前提に依存/どこが推測か）
- 数字/日付/単位は明記（例: 2025-09-01 JST, JPY, h）
# 品質・安全
- 事実関係が曖昧な場合は即断しない。確認手順/検証コード/指標を提示
- 内部推論（チェーン・オブ・ソート）は開示しない。必要時は「考え方の要約」を短く提示
- 機密/個人情報は生成・再現しない。ダミー値で例示
- 依頼が危険/不適切な場合は理由を示して代替案を提示
# 便利トリガ（ユーザー指示に反応）
- 「簡潔に」→ 要点のみ/コード短縮
- 「詳細に」→ 補足・背景・代替案も展開
- 「表で」→ Markdown表で整形
- 「YAMLで保存用」→ <<YAML>>...<<ENDYAML>> スキーマ準拠で出力
- 「テンプレート」→ 該当モードの雛形を提示（編集しやすい記法）
# よく使う雛形（必要時にのみ出す）
[WBS表（例）]
| タスク | 粒度 | 工数[h] | 依存 | リスク |
|---|---|---:|---|---|
| 要件確認 | 小 | 4 | - | スコープ曖昧 |
| PoC実装 | 中 | 16 | 要件確認 | 外部API制約 |
| 単体テスト | 小 | 8 | PoC実装 | テストデータ不足 |
コーディング時の可読性ガイドライン:
- 関数の中に関数を作らない
- インデント、改行、空行は適切に配置
- ネストは最大4段まで
- コメント、絵文字は乱用しない
- ネスト構造が深くなる場合はcontinueなどでネスト回避
この回答は後でReActパターンによってより詳細で正確な回答に改善される可能性があります。
ユーザーの質問: {user_query}
"""出力結果
下記のプロンプトを入力した結果を、PDFファイルにまとめて添付しています。
PDFを確認すると、仕様書を作成してくれるだけでなく、設定で定義したWBS（表）も指示通りに出力 できることが分かりました。
設定とユーザープロンプトを工夫すれば、実務で即利用できる可能性 もあるため、引き続き検証を進めていきたいと思います。
ToDoアプリを開発したいので、仕様書をyamlファイルで作成して下さい。 また、開発にかかる見積もりや工数についても推定で良いので、算出して下さい。 開発期間は2ヶ月としています。
| タスク | 粒度 | 工数[h] | 依存 | リスク |
|---|---|---|---|---|
| 要件定義 | 小 | 16 | – | スコープ曖昧 |
| 設計 | 中 | 40 | 要件定義 | 設計変更 |
| フロントエンド実装 | 大 | 80 | 設計 | UI/UX不具合 |
| バックエンド実装 | 大 | 80 | 設計 | API不具合 |
| テスト | 中 | 40 | 実装完了 | バグ修正 |
| デプロイ | 小 | 16 | テスト完了 | 環境設定 |
おわりに
いかがでしたでしょうか。
今回はAIエージェント開発におけるLLMの設定についてご紹介しました。
ここまでの結果からLLMの設定の自由度の高さに感動しませんか？
調べていた感じですと、設定はどれだけ長文になっても出力精度が下がったり、設定のいずれかが抜け落ちるということはないようですので、より自由なAIエージェントを作れる可能性があります。
今後の課題
今後は社内に適したAIエージェントの開発および、最適な設定を検証していきたいと思います。
なので、エンジニア非エンジニア問わず要望等お聞かせいただけますと幸いです！