社内の新規事業の提案を Power Automate で受け、記入の不足と審査の区分を判定して、経営企画の審査の台帳に入れる

処理の起点を決める

Forms の回答が送信されたときに、1件ずつ動かします。 トリガーは Microsoft Forms のコネクタの「When a new response is submitted」です。返ってくるのは回答の ID（responseId）で、続けて「Get response details」にフォームの ID と回答の ID を渡し、12の欄の値を受け取ります。

提案の様式がグループのフォームの場合は注意が要ります。 公式の既知の制限として、グループのフォームはドロップダウンに出てこず、フォームの ID を手で入れる必要があるとされています。ID はフォームを編集するときのアドレス欄にあり、FormId= の後ろの部分だけを貼ります。事務局のチームで作ったフォームはこれに当たることが多いので、最初に確かめます。

このコネクタは組織のアカウントでしか動きません。 協業先など社外からの提案は別の窓口で受けます。

止まった提案を拾い直すため、毎朝1回、台帳に無い回答を探す別のフローを置きます。

入力データを集める

質を決めるのは、事業部の一覧です。 主なサービスの名前が並んでいなければ、「既存事業の延長か」をAIは文面の印象で判定することになります。 社内の略称や旧名も入れます。

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

Get response details の出力は動的で、欄は質問の文に結び付きます。 様式の文を変えたら、フローを開き直して参照を確かめることを事務局の手順に書きます。

AIへ渡す前に整形する

1. 必須の欄の空を先に拾う … 8つの必須の欄のうち、空白だけのもの・「なし」「未定」だけのものを条件で見つけます。ここで拾えるものは、AIに判定させずに empty にします
2. 本文をまとめる … 12の欄を「【欄の名前】値」の形で1つの文につなぎます。欄の名前は様式の質問の文ではなく、決まった短い名前に置き換えます
3. 長さの確認 … 全体の字数を数え、極端に長いもの（12,000字を超える目安）は事務局へ回します
4. 社外の固有名詞の扱い … 「社外との関わり」の欄に書かれた企業名はそのまま渡しますが、台帳の一般の閲覧者には見えない列に入れます
5. 再提出の見分け … 同じ提案者の直近の提案で、状態が「差し戻し中」のものがあれば、題名の近さとあわせて再提出の候補とし、前回の差し戻しの理由を一緒に渡します
6. 事業部の一覧を添える … 事業部の名前と主なサービスの名前の短い一覧をプロンプトの入力にします

1番目を条件で先に拾うのは、空欄は機械で分かるからです。 AIには、書いてあるものが足りているかだけを見させます。

AIに処理させる

させるのは、2つの判定と、1つの短い書き出しだけです。

thin の判定の基準は、欄ごとに具体的に渡します。 「想定する顧客」なら業種・規模・役職のどれか1つ以上が特定されているか、「収益の見込み」なら誰がいくら払う形かが書かれているか、「最初の検証の案」なら何を何件で確かめるかが書かれているか。基準を渡さないと、文が長いものを filled、短いものを thin にします。

2行目がいちばん起きやすい失敗です。 「市場が大きく有望」のような一言が台帳に残ると、審査する側が先に読んでしまいます。出力の形にも評価を書く場所を作りません。

指示内容を固定する

あなたは社内の新規事業の提案制度の事務局で、届いた提案の受付の確認をします。
提案の良し悪しは判断しません。記入が足りているかと、回し先を決めるための印だけを返します。

【必須の欄と、filled とする基準】
- issue（課題）……誰の、どんな困りごとかが書かれている
- customer（想定する顧客）……業種・規模・役職のうち1つ以上が特定されている
- solution（解決のしかた）……何を提供するかが具体的に書かれている
- difference（既存の手段との違い）……比べる相手と違いが書かれている
- revenue（収益の見込み）……誰が何に対して払う形かが書かれている
- team（必要な体制）……必要な役割か人数が書かれている
- first_test（最初の検証の案）……何を、どれくらいの数で確かめるかが書かれている
- external（社外との関わり）……関わる社外の相手の有無が書かれている

【status の選び方】
- filled … 上の基準を満たしている
- thin …… 書いてあるが基準を満たしていない。missing_point に足りない点を一文で書く
- empty … 書いていない（空欄の判定はこちらで済ませてあるので、渡された欄だけ見る）
迷ったときに filled を選ばないでください。

【印の付け方】
- business_relation：提案のサービスや顧客が【事業部の一覧】の扱いと重なれば
  existing_extension、重ならなければ new_domain、判断できなければ unclear
- external_relation：他社との提携・共同開発は partnership、出資・買収は investment、
  記載が無ければ none、判断できなければ unclear
- data_domain：個人情報を扱う記載があれば personal_data、金融・医療・教育など
  規制のある領域に触れる記載があれば regulated、無ければ none、迷えば unclear
- 印ごとに、根拠にした提案の文を evidence にそのまま写してください。

【厳守事項】
- 審査の区分（事業部審査・新規事業審査会・拡大審査）を書かないでください。
- 提案の評価、採否の見込み、市場性についての意見を書かないでください。
- 提案に書かれていないことを補って filled にしないでください。
- missing_point は提案者に向けた依頼として使います。
  「〜が書かれていません」ではなく「〜を書き足してください」の形で書いてください。
- 前回の差し戻しの理由が渡された場合は、その点が直っているかを resubmit_check に書いてください。
- JSON のマークダウンを付けずに、JSON だけを返してください。

【提案】{proposal_text}
【事業部の一覧】{division_list}
【前回の差し戻しの理由】{previous_reason}

「迷ったときに filled を選ばない」を書かないと、thin が減ります。 迷ったら thin に倒し、事務局が原文で filled に戻すほうが、薄い記入が審査の場に届くより安く済みます。

最後の行は公式の FAQ に沿っています。 JSON を作れなかったというエラーは、モデルが JSON の前後に余計な情報を付けたことが原因のことがあり、「Don't include JSON markdown in your answer」の趣旨の一文を足すとよいとされています。

出力形式を固定する

プロンプトの出力を JSON にし、次の例を与えて形を「Custom」にします。

{
  "fields": [
    { "name": "customer", "status": "thin",
      "missing_point": "対象とする企業の業種か規模を書き足してください",
      "evidence": "中小企業全般" }
  ],
  "business_relation": "new_domain",
  "external_relation": "partnership",
  "data_domain": "personal_data",
  "relation_evidence": [
    { "flag": "external_relation", "field": "external",
      "evidence": "A社の決済の仕組みと連携する" }
  ],
  "resubmit_check": ""
}

fields には必須の8つの欄の分を並べます。1つ目の理由は、記入の判定と区分の印を別の場所に置けることです。 差し戻しの文面は fields から、区分は3つの印から作り、片方の決まりを変えてももう片方に影響しません。

2つ目は、形が固定されることです。 公式の説明では、JSON の例を書き換えると形式が「Custom」になり、テストし直しても更新されません。保存した時点の形がフローでの実行時に使われ、変わりません。 例の書き換えの後は「Save custom」で保存しないと変更が失われるとされているので、手順に入れます。なお、生成された JSON のスキーマは表示できますが、今のところ直接は編集できず、キーの無い配列だけの形は使えません。 fields を名前付きの要素の配列にしているのはこのためです。

3つ目は、evidence で確認が速くなることです。 原文の12の欄を最初から読み直さずに済みます。

区分は、フローの条件分岐で次のとおり決めます。 決まりは SharePoint の「区分の決まり」のリストに置き、フローはそれを読んで使います。

unclear が1つでもあれば区分を空にします。 迷う提案に区分を仮置きすると、事務局が承認の画面で見落としたときにそのまま回ります。

システムへ連携する

承認は、公式の手順にある「Start and wait for an approval of text」を使います。 提案の文面を「Suggested Text」に入れて事務局に割り当てると、事務局は Power Automate の承認の画面で文面を直してから応答でき、承認か却下かでフローが分かれます。 差し戻しの文面をAIが作ったまま送る経路を作らないための仕組みです。

審査の台帳への登録は Create item で、承認の後の状態の更新は Update item で行います。 台帳は汎用のリスト（カスタムリスト）で作ります。公式の制限として、Power Automate のリストのフローは汎用のリストと汎用のドキュメントライブラリでしか動かず、お知らせ・連絡先・予定表・タスクなどのテンプレートのリストには対応していないとされています。既存の台帳がタスクのリストで作られていたら、作り直しが要ります。

SharePoint のコネクタの上限は、接続ごとに60秒あたり600回の呼び出しです。 毎朝の拾い直しで台帳を1件ずつ読む作りにせず、Get items の Filter Query で絞ってまとめて読みます。

人が確認する

事務局が承認の画面で見るのは、次の順番です。

1. 区分が空の提案を先に開く … unclear の印がある提案です。根拠の抜き書きを読み、必要なら原文に当たって区分を決めます
2. thin の欄の一文を読む … 足りない点の書き方が提案者に失礼でないか、本当に足りないかを見ます。thin が3つ以上ある提案は、原文を一度通して読みます
3. 拡大審査に回る提案の根拠を確かめる … 法務と財務の同席を頼むことになるので、partnership・investment・regulated の根拠の文が本当にそう読めるかを見ます
4. 承認する … 文面を直して承認すると、提案者への連絡と台帳の更新が進みます
5. 判定を覆したら記録する … どの欄の判定や、どの印を、どちらに変えたかを判定のログに残します

3番目を省かないでください。 提携の記載を読み違えて回すと、提案者も法務・財務も空振りの準備をすることになります。

目標は、60件をならして1件8分です。 印の付いていない、区分が決まった提案は、承認の画面で一覧を見て数分で承認できます。時間を使うのは、区分が空のものと thin の多いものです。

例外に対処する

上から3行目までが大半です。 失敗の理由は台帳の列に日本語で書き、事務局が状態の列だけで見分けられるようにします。

記録を残す

• 回答の ID、受付の日時、提案者、題名
• AIに渡した本文と、返ってきた JSON の全文
• フローが決めた区分と、そのとき使った区分の決まりの版
• 事務局の承認の結果、直した差し戻しの文面、承認した人と日時
• 事務局が判定や印を覆した記録 … どの欄・どの印を、どちらに変えたか
• 差し戻しから再提出までの日数

3つ目で決まりの版を残すのは、決まりが後から変わるからです。 拡大審査に回す条件を見直したとき、過去の提案がどの決まりで回ったかが分からないと、回し直しの範囲が決まりません。

5つ目は、プロンプトを直す材料です。 同じ欄で thin を filled に戻すことが続くなら、その欄の基準が厳しすぎます。