研究開発の各テーマから毎月出る進捗報告を、経営向けの研究開発ポートフォリオの概要にまとめ、前月からの変化と判断が要る事項を示す

処理の起点を決める

毎日夜に動く定時のフローにし、その日が第2営業日のときだけ先へ進めます。 「繰り返し」のトリガーで頻度を日、実行する時刻を夜に指定し、タイム ゾーンを日本に合わせます。営業日の判定は、会社の休日を並べたリストを引いて行います。月の頻度で「毎月2日」にすると、2日が休日の月にずれます。

締めに遅れた報告は、第3営業日の夜にもう一度拾います。 第2営業日の実行で報告が無かったテーマを覚えておき、翌日の実行ではそのテーマだけを要約します。それでも出ていないテーマは、概要に「報告未提出」と載せます。 未提出を空欄にすると、経営会議で「動きが無い」と読まれます。

リーダーが報告を出したたびに動かす形は取りません。 要約は個別に作れますが、前月との比較と段階別の総括は全テーマがそろってからでないと書けないためです。

入力データを集める

質を決めるのは、テーマ台帳のマイルストーンです。 「年度内に試作」のような粗い予定しか無いテーマは、見込み日と比べようがありません。区分を規則で決めるには、マイルストーンごとに日付が入っていることが前提です。 日付の無いテーマは、区分を「判定不可」にして概要に載せます。

前月の要約は、AIの出力をそのまま残したものを使います。 担当者が直した後の版を残し、翌月はそれと比べます。 直す前の版と比べると、担当者が直した箇所が「変化」として出てきます。

データの取得方法を決める

台帳は「進行中」のテーマだけを引きます。 中止や完了になったテーマを含めると、報告が無いことが「未提出」として出てきます。台帳にあって報告が無いテーマと、報告があって台帳に無いテーマの両方を、フローで突き合わせます。 後者は、台帳への登録漏れです。

AIへ渡す前に整形する

1. 報告のそろいの確認 … 台帳の進行中のテーマと、報告を突き合わせます。未提出と、台帳に無い報告を分けて印を付けます
2. 進みの区分の決定 … マイルストーンごとに、見込み日 − 予定日 の日数を計算し、段階ごとの規則の表で区分を決めます。テーマの区分は、マイルストーンの中でいちばん悪い区分にします
3. 関門の審査の印 … 審査の予定月が当月か翌月のテーマに印を付けます
4. 社外の名前の置き換え … 報告の中の共同研究の相手、顧客、委託先の名前を、置き換え表で 共同研究先A のような表記にします
5. 欄に番号を振る … 報告の6つの欄を R1〜R6 とし、欄の中の文に R3-02 のような番号を付けます
6. AIに渡す単位を作る … テーマごとに、報告の文、台帳の項目、区分とその理由（何日ずれているか）を1つにまとめます

2番目で「いちばん悪い区分」にするのは、楽観に寄らないためです。 3つのマイルストーンのうち2つが予定どおりでも、1つが大きく遅れていれば、テーマとしては遅れです。どのマイルストーンが区分を決めたかを、要約に一緒に載せます。

6番目でまとめる1テーマ分は、次のような形です。

テーマ: T-014 高耐熱樹脂の量産試作（段階: 製品化）
区分: delayed（規則の版 2026-04）
区分を決めたマイルストーン: M3 量産試作の完了 予定 2026-11-30 見込み 2026-12-24（24日遅れ）
関門の審査: 2026-12（当月・翌月ではないため印なし）
R1-01 今月は試作設備の据え付けを行った。
R2-01 小型機での耐熱試験は目標値を満たした。
R3-01 試作設備の立ち上げが、部品の納入遅れで3週間ずれた。
R3-02 量産時の金型の寿命が未確認。
R4-01 来月は設備の試運転と、金型の耐久試験に着手する。
R5-01 M3 の見込み日は 2026-12-24。
R6-01 （経営への相談の欄は空欄）

5番目は、第3章の（c）への対策です。 「課題」欄の最後に書かれた相談も、R3-05 のような番号で渡されるので、AIは欄ではなく文の中身で拾えます。 拾った根拠の番号が付くので、担当者はその文だけを確かめれば済みます。

AIに処理させる

させるのは、テーマごとに報告を決まった項目に要約することと、判断が要る事項を報告の記載から拾うことです。進みの区分は渡したものを使わせ、決めさせません。

「判断が要る事項」は、報告がはっきり求めているものに限ります。 「ご検討いただきたい」「ご判断をお願いしたい」「追加の予算が必要」のように、リーダーが判断や支援を求めている文です。関門の審査の印が付いたテーマは、それとは別に「関門の審査が翌月」として一覧に載せます。

段階別の総括は、要約がそろってから別に書かせます。 材料は要約のJSONだけで、報告の原文は渡しません。 原文を渡すと、総括に要約に無い細部が入り、担当者が確かめる範囲が広がります。

指示内容を固定する

あなたは研究開発本部の企画管理部で、経営会議向けに各テーマの進捗を要約する担当です。
渡された報告とテーマ台帳に書かれていることだけを根拠にしてください。

【書くこと】
テーマごとに、今月の進み、区分の理由、課題（3つまで）、判断が要る事項、
次月の予定を書いてください。

【厳守事項】
- 進みの区分は、渡された status をそのまま使ってください。変えないでください。
  報告の書きぶりが楽観的・悲観的でも、区分を言い換えないでください。
- 区分の理由には、区分を決めたマイルストーンと、渡された遅れの日数をそのまま書き、
  遅れの原因として報告に書かれていることを添えてください。
  原因が書かれていなければ「原因の記載なし」と書いてください。
- 各文に、根拠にした報告の文の番号（R1-01 など）を付けてください。
  番号を付けられない文は書かないでください。
- 判断が要る事項は、報告の中で経営・本部に判断や支援を求めている文だけを挙げてください。
  どの欄に書かれていても拾ってください。
  あなたの考えで「中止を検討すべき」「資源を増やすべき」などを書き足さないでください。
- 報告に無い課題やリスクを指摘しないでください。
- 研究の成果が有望かどうかを評価しないでください。
- 日数・数量を計算しないでください。渡された値をそのまま使ってください。
- 社外の名前は、置き換えた表記（共同研究先A など）のまま使ってください。
- 1テーマの要約は全体で200字以内にしてください。

【テーマ台帳の項目】{theme}
【進みの区分と、区分を決めたマイルストーン・遅れの日数】{status}
【報告（文の番号付き）】{report}

「区分を言い換えない」まで書くのは、AIが要約の文で区分をやわらげるからです。 区分は「遅れ」でも、本文に「概ね順調に推移」と書けば、経営はそちらを読みます。区分と本文が食い違う概要は、区分を規則で決めた意味をなくします。

「どの欄に書かれていても拾う」は、第3章の（c）をそのまま指示にしたものです。 欄の名前だけで探させると、「経営への相談」欄が空のテーマからは何も出てきません。

出力形式を固定する

次の形のJSONで受け取ります。 Azure OpenAI の構造化出力を使い、JSON Schema に沿った形で返させます。

{
  "theme_id": "",
  "period": "2026-09",
  "status": "on_track | delayed | at_risk | not_assessable | not_submitted",
  "progress": [ { "text": "", "sources": ["R1-02", "R2-01"] } ],
  "status_reason": { "milestone": "", "delay_days": 0, "cause": "", "sources": ["R3-01"] },
  "issues": [ { "text": "", "sources": ["R3-02"] } ],
  "decisions_requested": [ { "text": "", "sources": ["R3-05"] } ],
  "next_month": { "text": "", "sources": ["R4-01"] }
}

1つ目の理由は、status を enum で縛り、渡した値のまま返させられることです。 構造化出力は enum に対応しているので、区分が「概ね順調」のような6つ目の値に崩れることがありません。フローは返ってきた status が渡した値と同じかを確かめ、違えば渡した値で上書きして印を付けます。

2つ目は、項目ごとに配列で持てるので、前月との比較が項目どうしでできることです。 区分は値の比較、課題と判断が要る事項は前月の配列との突き合わせで、「新しく出た」「解消した」「続いている」を出します。 課題の文面は毎月少しずつ違うので、突き合わせは根拠の文ではなく、課題の要約どうしを Azure OpenAI に対で渡して「同じ課題か」だけを答えさせます。

3つ目は、空の配列で「無い」を表せることです。 構造化出力ではすべての項目を必須にする決まりがあるので、decisions_requested が空なら判断を求める文が無かったことがはっきりします。書き忘れと区別できます。

前月との比較の結果は、フローが次のような表にして概要の冒頭に置きます。

4行目のように、区分が変わらなくても判断が要る事項が出たテーマは「変化あり」に入れます。 区分だけで変化を拾うと、課題欄の最後に書かれた相談がまた埋もれます。

段階別の総括は、この表と要約のJSONだけを渡して、別の呼び出しで書かせます。 指示は短く、「区分の件数、区分が悪くなったテーマ、判断が要る事項を、段階ごとに3〜5文で整理してください。テーマの評価や今後の提案を書かないでください。各文にテーマの番号を付けてください」とします。総括の1文ごとにテーマの番号が付くので、担当者は一覧の該当行と照らすだけで確かめられます。

システムへ連携する

概要の一覧は、繰り返しセクションのコンテンツ コントロールで表の行にします。 テーマの数は月によって変わるので、フローで値の配列を作って渡します。コントロールの名前はテンプレートの中で一意にする必要があります。総括の本文はプレーン テキストのコントロールにし、「複数の段落」を許可しておきます。リッチ テキストのコントロールには対応していません。

一覧の並びは、変化のあったテーマを先にします。 区分が悪くなったテーマ、判断が要る事項のあるテーマ、関門の審査が近いテーマ、それ以外の順です。経営会議で上から読めば、議論が要るところに先に着きます。

人が確認する

企画管理部の担当者が重点を置くのは、変化のあったテーマと、判断が要る事項です。

1. 区分が悪くなったテーマの理由を確かめる … 区分を決めたマイルストーンと遅れの日数、原因の要約を、報告の根拠の文と照らします
2. 判断が要る事項の根拠を開く … 拾われた文が、本当に判断や支援を求めているかを確かめます。拾い損ねが無いかは、「経営への相談」欄が空のテーマを流し見て確かめます
3. 「判定不可」と「報告未提出」のテーマに連絡する … マイルストーンの日付が無いテーマには台帳の更新を、未提出のテーマには提出を頼みます
4. 段階別の総括を直す … 要約に無いことが入っていないかを見ます
5. 直した箇所を記録する … どのテーマの、どの項目を直したかを残します

区分そのものは、担当者も直しません。 区分がおかしいと思ったら、台帳の予定日か規則の表のほうを直します。 その月の概要で区分だけを手で変えると、翌月の比較が狂います。

目標は、60件をならして1件12分です。 変化の無いテーマは数分、区分が悪くなったテーマと判断が要る事項のあるテーマは報告に戻って確かめるので長くなります。

例外に対処する

上から4行目が、いちばん気をつけたい例外です。 見込み日が空のテーマを予定どおりとみなすと、書かないほうが良い区分になるという仕組みができてしまいます。リーダーが見込み日を書かなくなります。

記録を残す

• 実行の日時と、対象月、集めた報告の一覧
• テーマごとの区分の計算（マイルストーン、予定日、見込み日、差の日数、規則の版）
• Azure OpenAI に渡した指示と、返ってきたJSONの全文
• 担当者が直した後の要約（翌月の比較に使う版）
• 前月との比較の結果（区分の変化、新しい課題、解消した課題）
• 経営企画部へ渡した概要のファイルと、渡した日時
• 経営会議で取り上げられた判断が要る事項と、その結論

4つ目を「直した後」の版で残すのは、第7章の入力データで書いたとおりです。 ここを取り違えると、翌月の「変化」に担当者の手直しが混ざります。

最後の行は、翌月の要約と突き合わせるために残します。 判断が出た事項が翌月の報告でまた相談として出てきたら、結論がテーマ側に届いていないことが分かります。