この記事で分かること

  • 金融実務で生成AIの回答精度を左右するのは、モデルの性能以上に「指示(プロンプト)の設計」であること
  • 役割・文脈と入力・出力形式と制約・検証指示の「4点セット」でプロンプトを組み立てる設計原則
  • 決算短信の要約・差異コメント作成・表データ分析の3場面での悪い例→良い例のビフォーアフター
  • 数値の原本照合・出典付き回答の指示・機密情報を入れないという、金融実務ならではの運用ルール

結論:プロンプトは「役割・文脈と入力・形式と制約・検証指示」の4点セットで書く

生成AIに財務の仕事を手伝わせるとき、出力の品質を最も大きく左右するのは、どのツールを使うかではなく「何を、どう指示するか」です。この指示の設計技術をプロンプトエンジニアリング(Prompt Engineering)と呼びます。金融実務では、①役割(誰として答えるか)、②文脈と入力(前提・対象・根拠資料の範囲)、③出力形式と制約(形式・分量・単位・禁止事項)、④検証指示(根拠の提示・不明時の扱い)の4要素を必ず含める、と覚えておけば大きく外しません。そのうえで、出力された数値は必ず人が原本と照合すること、未公表情報や機密情報を入力しないことをセットで運用します。本記事では、この原則を日本語の具体例で解説します。

なぜ金融実務ではプロンプト設計が効くのか:3つの制約

プロンプトの4要素(4点セット) ① 役割 Role 誰として答えるかを指定する 例:「日本企業の決算資料に詳しい財務アナリストとして」 ② 文脈と入力 Context / Input 前提・対象期間・根拠資料の範囲を明示する 例:「対象は2026年3月期通期。以下の決算短信の本文のみを根拠とする」 ③ 出力形式と制約 Format / Constraints 形式・分量・単位・禁止事項を指定する 例:「箇条書き5点以内。金額は百万円単位。資料にない数値は書かない」 ④ 検証指示 Verification 根拠の提示方法と、不明なときの扱いを指定する 例:「各数値の直後に該当ページを付す。不明な場合は『不明』と書く」
図1:プロンプトの4要素。この4点を毎回そろえるだけで、金融実務での出力品質は目に見えて安定します。

一般的な文章作成であれば、指示が多少あいまいでも「それらしい」出力が得られれば十分なことも多いでしょう。しかし金融実務には、他の業務にはない3つの制約があります。

第一に、数値精度の制約です。売上高の桁が1つ違えば、あるいは増減率の符号が逆になれば、報告を受けた側の意思決定を誤らせます。生成AIは文章の流れとして「もっともらしい数値」を作ってしまうことがあるため、数値をどこから取り、どう検算させるかを指示の段階で設計する必要があります。

第二に、出典の制約です。財務の報告資料は社内レビューで「この数字の根拠は何か」と必ず問われます。根拠を示せない記述は、内容が正しくても実務では使えません。したがって、出力に根拠箇所を付けさせる指示が標準装備になります。

第三に、機密の制約です。未公表の業績情報や取引情報は、そもそも外部のAIサービスに入力できない場合が多く、入力してよい情報の範囲が社内規程で定められているのが通常です。プロンプト設計は「何を入れるか」だけでなく「何を入れないか」の設計でもあります。

この3つの制約があるからこそ、指示の設計がそのまま成果物の品質と業務の安全性に直結します。生成AIを金融実務のどの場面で使えるかの全体像は生成AIの金融実務活用で整理していますので、あわせてお読みください。

4要素の設計原則

図1の4要素を、順に見ていきます。

① 役割(Role)。「あなたは日本企業の決算資料に詳しい財務アナリストです」のように、AIに立場と専門性を与えます。役割を指定すると、用語の選び方や説明の深さが読者の期待に近づきます。凝った人物設定は不要で、職種と対象領域を1文で示せば十分です。

② 文脈と入力(Context and Input)。対象会社・対象期間・資料の種類など、人間の部下に仕事を頼むときに伝える前提を省略せずに書きます。特に重要なのが根拠資料の範囲の限定です。「以下に貼り付けた資料のみを根拠とし、あなたの一般知識で補わないでください」と明示すると、資料にない情報を混ぜ込む「もっともらしい創作」を大きく減らせます。

③ 出力形式と制約(Format and Constraints)。箇条書きか表か、何字以内か、金額の単位は何か、といった形式の指定に加えて、禁止事項を書きます。「資料にない数値は書かない」「断定的な将来予測はしない」などです。形式が定まっていると、出力をそのまま社内資料の下書きに流用しやすくなります。

④ 検証指示(Verification)。「各数値の直後に根拠箇所を付す」「不明な場合は推測せず『不明』と書く」のように、後工程の人間による検証を前提とした出力を求めます。AIに「分からないことは分からないと言ってよい」という逃げ道を与えることは、無理な創作を防ぐうえで効果的だと各社の公式ガイドでも紹介されています。

悪い例→良い例:3つのビフォーアフター

4要素を実際のプロンプトに落とし込むと、どれほど変わるかを3つの場面で見てみます。いずれも設例は仮のものです。

設例1:決算短信の要約

悪い例:「この決算短信を要約してください。」

これでは、分量も観点も根拠の扱いも指定されておらず、汎用的な要約が返ってくるだけです。増減率をAIが自前で計算して誤る余地も残ります。

良い例:

あなたは日本企業の決算資料に詳しい財務アナリストです。以下に貼り付ける決算短信(2026年3月期・通期)のサマリーと「経営成績に関する説明」を読み、経営会議向けの要約を作成してください。
・箇条書き5点以内、各60字以内
・売上高・営業利益・当期純利益は前期比増減率とあわせて記載(単位:百万円)
・増減の理由は、短信に記載された説明のみを根拠とする
・各項目の末尾に根拠箇所(例:添付資料p.2)を括弧で付す
・短信に記載のない数値や理由は書かない。不明な点は「記載なし」と明記する

役割・対象資料の範囲・形式・単位・根拠の付し方・禁止事項がすべて入っています。決算短信や有価証券報告書のどこに何が書かれているかは有価証券報告書の読み方で解説しています。

設例2:予実差異コメントの作成

悪い例:「この予実差異についてコメントを書いてください。」

良い例:

あなたは事業会社の経営企画部で月次報告を担当するアナリストです。以下のMarkdown表は当社X事業の2026年6月単月の予実対比です(単位:百万円)。
(ここに表を貼る)
この表に基づき、経営層向けの差異コメント案を作成してください。
・費目ごとに「差異額・差異率・考えられる要因の仮説」の順で記述(差異率は小数第1位まで)
・要因はあくまで仮説であることを明記し、断定しない
・計算に使う数値は表の値のみとし、表にない数値を補わない
・全体で400字以内

差異の「要因」は表からは読み取れないため、仮説と断定を区別させるのがポイントです。AIの出した仮説はたたき台にとどめ、現場への確認を経て確定させます。数値を報告としてどう語るかはデータストーリーテリングも参考になります。

設例3:表データの分析

悪い例:(表のスクリーンショットだけを貼って)「この表を分析してください。」

良い例:

以下のCSVは当社の製品別売上高の四半期推移です(単位:百万円、FY2025Q1〜FY2026Q1の5四半期)。
(ここにCSVを貼る)
次の3点を分析してください。
1. 四半期ごとの合計売上高と前四半期比増減率(小数第1位まで)
2. 直近四半期の増減に寄与が最も大きい製品とその寄与額
3. 傾向が変化した製品があれば、その変化点
計算過程を先に示し、最後に結論を3行でまとめてください。私が原本と照合するため、途中の数式は省略しないでください。

分析の観点を番号で列挙し、計算過程を開示させることで、後の照合が容易になります。

表形式データの渡し方:Markdown表・CSV・スクリーンショットの使い分け

財務の仕事はほとんどが表データとの格闘です。渡し方には主に3通りあります。

渡し方向いている場面注意点
Markdown表数行〜数十行の小さな表。予実対比・要約表など列の対応関係が明確で誤読が少ない。列見出しに単位を書く
CSV(カンマ区切り)行数が多いデータ。時系列・明細データ桁区切りカンマは事前に除去する。1行目に列名、プロンプト側に単位を明記
スクリーンショットレイアウト自体を見せたいときの最終手段画像からの数値読み取りは誤りが起きやすい。数値を使う分析には原則使わない

原則は「計算させたい数値はテキストで渡す」です。画像から読み取らせた数値をそのまま計算に使うのは、転記ミスを組み込むようなものだと考えてください。また、Excelの表を貼り付けると桁区切りカンマや全角数字が混ざることがあるため、渡す前に整形しておくと精度が安定します。

長い資料の分割と要約の段階化

有価証券報告書のような長い資料を丸ごと渡して「要約して」と頼むと、重要な箇所が薄まった総花的な要約になりがちです。実務では段階化が有効です。すなわち、①資料を章・セクション単位に分割する、②各セクションを同じ形式で個別に要約させる、③個別要約を並べて渡し、全体の統合要約を作らせる、という3段階です。各段階の指示を同じテンプレートで統一すると、出力の粒度がそろい、統合時の品質が上がります。長文の一括処理に対応したツールでも、この段階化は「どこから来た記述か」を追跡しやすくするという検証面の利点があります。

出典付き回答を得る指示

「各数値・各主張の直後に、根拠となる資料の該当箇所(ページ番号・表名・見出し)を括弧で示してください。該当箇所を示せない記述は出力に含めないでください」——この一文を加えるだけで、検証にかかる時間は大きく減ります。根拠の引用を主張のすぐ近くに付けさせる形式は、誤った記述の抑制にも役立つとMicrosoftの公式ガイドで紹介されています。注意すべきは、ここでいう出典は「あなたが渡した資料の中の箇所」だという点です。渡していない外部情報の出典をAIに挙げさせると、実在しない文献をもっともらしく挙げてしまうことがあるため、外部出典は必ず自分で原典に当たって確認します。

段階思考(Chain-of-Thought)の使いどころと限界

「段階を追って考え、途中の計算過程を示してから結論を述べてください」と指示する手法を段階思考(Chain-of-Thought, CoT)プロンプティングと呼びます。複数ステップの計算や条件分岐のある判断では、過程を書かせることで誤りが減り、どこで間違えたかを人間が特定しやすくなるという利点があります。財務モデルの検算のような用途とは相性のよい手法です(AI支援モデリング、詳細はAIによるモデルレビューを参照)。

ただし限界も明確です。第一に、過程がもっともらしく見えることと、正しいことは別物です。整然とした計算過程の中に誤りが紛れることはあり、見た目の論理性に安心して検証を省くのが最も危険です。第二に、近年の推論機能を内蔵したモデルでは、明示的な段階思考の指示が不要な場合や、推奨されない場合があります。ツールの世代によって最適な指示は変わるため、CoTは「常に付ける呪文」ではなく、検証可能性を高めたいときに選ぶ手段と位置づけるのが実務的です。

検証工程:数値は必ず原本と照合する

入力 → 出力 → 検証 → 修正のワークフロー ① 入力を設計 資料+4要素プロンプト ② AIが出力 下書き・計算過程 ③ 人が検証 数値は原本と照合 OK ④ 成果物として利用 責任は使う人が負う NG:誤り箇所を指摘し、修正指示を追加して再実行 NG
図2:検証で問題が見つかったら、修正指示を追加して再実行します。最終責任は常に使う人間の側にあります。

どれほどプロンプトを工夫しても、検証工程は省略できません。実務でのルールはシンプルで、「AIの出力に含まれる数値は、1つ残らず原本(決算短信・元帳・元のExcel)と照合してから使う」です。要約や文章のトーンは多少の揺れが許容されますが、数値の誤りは許容されないためです。照合の手間を減らすには、前述のとおり出力側に根拠箇所と計算過程を付けさせておくことが効きます。また、検証で誤りを見つけたときは、ゼロから書き直させるのではなく「○○の増減率の計算が誤っています。表の値を使って再計算してください」のように誤り箇所を特定して修正指示を出すほうが、速く安定した結果になります。

機密情報を入れない原則

最後に、最も重要な運用原則です。未公表の重要事実(業績・M&A情報など)、顧客・取引先の非公開情報、個人情報は、社外の生成AIサービスに入力しないのが出発点です。多くの会社では、利用してよいツール・入力してよい情報の範囲・ログの扱いが社内規程で定められています。プロンプトの工夫より先に、まず自社の規程を確認してください。実務上は、設例のように数値を架空の値に置き換える、会社名を伏せ字にするだけで足りる場面も多くあります。「便利だから」と規程の外で使うことは、キャリア上のリスクとしても最大級だと認識しておくべきです。

よくある質問(FAQ)

Q. プロンプトのテンプレートを一度作れば、ずっと使い回せますか?
A. 4要素の骨格は使い回せますが、中身は業務ごとに調整が必要です。月次の差異コメントのような定型業務では、テンプレート化して部署内で共有する価値が高い一方、モデルの世代交代で最適な書き方が変わることもあるため、四半期に一度程度は見直すことをおすすめします。

Q. 英語で書いたほうが精度は上がりますか?
A. 以前は英語優位と言われましたが、近年の主要モデルは日本語の指示でも実用水準で動きます。日本語の財務資料を扱うなら、指示も日本語のほうが用語の対応(例:経常利益のような日本固有の概念)で混乱が起きにくい面もあります。それよりも、本記事の4要素がそろっているかどうかのほうが精度への影響は大きいと考えてください。

まとめ

金融実務のプロンプトエンジニアリングは、特別な呪文集ではなく、「有能だが事情を知らない新人に、間違えようのない指示書を書く」技術です。役割・文脈と入力・出力形式と制約・検証指示の4点セットをそろえ、表データはテキストで渡し、長い資料は段階化し、出典と計算過程を出力させる。そして数値は必ず原本と照合し、機密情報は入れない。この一連の型を身につければ、生成AIは財務の現場で信頼できる下書き担当になります。まずは次の月次報告のひと場面で、悪い例を良い例に書き換えるところから試してみてください。

出典・参考(2026-08-01確認)

  • OpenAI「Prompt engineering」公式ガイド(developers.openai.com/api/docs/guides/prompt-engineering)
  • Anthropic「Prompt engineering overview」公式ドキュメント(platform.claude.com/docs/en/docs/build-with-claude/prompt-engineering/overview)
  • Microsoft Learn「Prompt engineering techniques」(learn.microsoft.com/en-us/azure/ai-services/openai/concepts/prompt-engineering)

※本記事は教育目的の一般的な解説であり、法務・税務・投資助言ではありません。設例は理解のための仮設例です。生成AIの利用にあたっては、所属組織の規程および各サービスの利用規約に従ってください。