取締役会の議案資料を各部門から集め、締切前の督促と、届いた資料の議案番号・付議区分・添付漏れの確認を済ませて事務局へ渡す

処理の起点を決める

トリガーは2つです。 1つは督促のための毎朝の定時実行、もう1つは形式の確認のための提出用のライブラリへのファイルの作成です。

督促を定時実行にするのは、「まだ届いていない」という出来事は起きないからです。 何かが起きるのを待つのではなく、毎朝リストを見て、締切までの日数で拾います。朝9時に回し、担当者が出社して最初に目にする時間に合わせます。

形式の確認は、ファイルが置かれたらすぐ動かします。締切の直前に届いた資料ほど、差し戻しの時間が残っていません。 1日1回まとめて見ると、夕方に届いた資料の差し戻しが翌日になります。

SharePoint コネクタのトリガーは、「ファイルが作成されたとき（プロパティのみ）」を使います。公式のリファレンスでは、ライブラリに項目が作成されたときに動き、列の値だけを返すので、中身は「ファイル コンテンツの取得」で取るとされています。フォルダを指定する「フォルダーにファイルが作成されたとき」は非推奨と表示されており、サブフォルダーに置かれたファイルでは動かないとされています。 会議ごとにフォルダを分けたくなりますが、会議日は列で持ち、フォルダは分けません。

入力データを集める

質を決めるのは、ライブラリの列です。 起案部門の担当者がファイルを置くときに、議案番号を選び、「本体」か「別紙」かを選び、別紙なら番号を入れます。 この列があれば、本文で触れた別紙と届いたファイルを機械的に突き合わせられます。

議案番号はリストから選ばせます。 担当者に手で打たせると、「第3号議案」「議案3」「3号」が混ざり、一覧と結び付きません。ライブラリの議案番号の列を、議案の一覧のリストを参照する列にします。

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

督促の側は、AIを使いません。 未提出かどうかと締切までの日数は、リストの値で決まります。AIに「督促が要るか」を判断させる理由がありません。 文面も段階ごとに定型にしておきます。

締切までの日数は営業日で数えます。 暦の日数で数えると、月曜が締切の議案に土曜の朝に督促が飛びます。会社の休日の一覧をリストで持ち、フローの中で営業日を数えます。 1件の議案に同じ段階の督促を二度送らないよう、送った段階をリストの列に書き込みます。

提出の状況の列は、フローだけが書き換えます。 事務局が手で「提出済み」にすると、ライブラリにファイルが無いのに督促が止まります。状況はファイルの到着で変わる、という一本の道にしておきます。

形式の確認の側は、ファイルの中身を取ってプロンプトに渡します。別紙のファイルが置かれたときは、本体のファイルの確認をやり直します。 本体だけが先に届いて「別紙3が無い」と出ていたものが、別紙3の到着で解消されるからです。

AIへ渡す前に整形する

1. 形式の確認 … PDF 以外のファイルは、プロンプトに渡さず担当者へ「PDFで置き直してください」と返します
2. サイズとページ数の確認 … ドキュメント入力は、ファイルの合計が25MB未満、50ページ未満である必要があるとされています。超えるものは事務局へ回します
3. 本体か別紙かの確認 … 列で「別紙」が選ばれたファイルは、本文の読み取りをせず、同じ議案の本体の確認をやり直す合図にします
4. 最新の版の特定 … 同じ議案番号の本体が複数あるときは、最も新しいものだけを確認の対象にし、古いものに「旧版」の印を付けます
5. 締切の超過の確認 … 締切を過ぎて届いたものは、確認の結果とは別に「締切後」の印を付けます
6. 一覧の行の整形 … 議案番号、件名、付議区分を、プロンプトに渡すテキストにまとめます

4番目を前処理で済ませるのは、版の取り違えが（d）の原因だからです。 版の判断を事務局の目に頼ると、古い版を法務に回すことがまた起きます。ライブラリの作成日時で、機械的に決めます。

2番目の上限に当たる資料は、まれにあります。 設備投資の議案に見積書と図面を全部付けると、50ページを超えることがあります。本体と別紙を分けて置いてもらえば、本体だけを読ませられます。

AIに処理させる

させるのは、資料の表紙と本文から3つのことを読み取ることです。

4行目は、付議区分の書き違いを見つけるための材料です。 表紙に「報告事項」とあり、本文の結びが「ご承認をお願いいたします」なら、どちらかが違っています。AIには矛盾の有無を判断させず、両方を写させて、突き合わせはフローで行います。

3行目がいちばん起きやすい失敗です。 一覧の議案番号を一緒に渡すので、表紙の番号が少し違っていても、AIは一覧の番号に「直して」返しがちです。それをされると、書き違いが見つからなくなります。

指示内容を固定する

あなたは取締役会の事務局で、各部門から届いた議案資料の形式を確認する担当です。
渡された資料（PDF）を読み、表紙と本文から次のことを読み取ってください。
内容の良し悪しや、付議すべきかどうかは判断しないでください。

【読み取ること】
1. 表紙に書かれた議案番号を、書かれているとおりに写す。
2. 表紙に書かれた付議区分（決議事項・報告事項・協議事項など）を、書かれているとおりに写す。
3. 本文の中で「別紙」「添付資料」「参考資料」と書かれた箇所をすべて挙げる。
   それぞれについて、番号と、その言葉が出てきた文を写す。
   番号の無いもの（「別紙のとおり」など）は number を "unnumbered" にする。
4. 本文の結びにある、会議に求めること（承認・報告・審議など）の文を写す。

【厳守事項】
- 議案の一覧の情報は、照らし合わせの参考として渡しています。
  表紙に書かれた値を、一覧の値に合わせて直さないでください。
- 書かれていない項目は推測で埋めず、空にして status を "not_found" にしてください。
- 別紙の言及は、同じ番号が何度出てきても、番号ごとに1つにまとめてください。
- 写す文は、資料の文字をそのまま写してください。要約しないでください。
- 「付議すべき」「不要」「問題ない」などの判断を書かないでください。
- 回答に JSON マークダウンを含めないでください。

【議案の一覧の該当行】{agenda_row}
【表紙の書き方の決まり】{cover_rules}
【資料】{document}

「一覧の値に合わせて直さない」を明記しないと、直してきます。 一覧を渡すのは、AIに「何を探せばよいか」を示すためですが、同時に「正解」に見えてしまいます。照らし合わせはフローの仕事だと、指示の側で線を引きます。

最後の行は、公式の FAQ にある対処です。 JSON 出力で「JSON を生成できませんでした」と出るときは、モデルが JSON をマークダウンで囲んでいることがあり、この一文を足すと解消することがあるとされています。

出力形式を固定する

次の形の JSON を、プロンプトの JSON 出力で受け取ります。

{
  "agenda_no": { "value": "", "status": "found | not_found" },
  "category": { "value": "", "status": "found | not_found" },
  "attachment_refs": [
    { "number": "1", "sentence": "" }
  ],
  "closing_request": ""
}

JSON の例を保存すると、形式は固定されます。 公式の説明では、例を更新すると形式が「カスタム」になり、テストし直しても更新されず、保存した形式が実行時に使われるとされています。フローの側で項目名を使うので、形式が実行のたびに変わらないことが要ります。 なお、フィールドのキーの無い配列（["1", "2"] のような形）はサポートされていないとされているので、別紙の一覧も number のキーを持つ要素の配列にします。

判定はフローの条件分岐で決めます。

別紙の突き合わせは、AIではなくフローで行います。 attachment_refs の番号の一覧と、ライブラリで同じ議案番号の「別紙」の番号の一覧を比べ、本文にあってライブラリに無い番号を「未着の別紙」として出します。

システムへ連携する

差し戻しの文は、事務局の承認を経てから送ります。 公式の説明でも、プロンプトの出力の後に承認のステップを足し、人がテキストを確かめて編集できる形が紹介されています。承認された文だけが、フロー ボットから担当者へ送られます。

督促は承認を通しません。 文面は定型で、未提出かどうかはリストの値なので、AIの出力を含まないからです。

人が確認する

事務局が開くのは needs_fix と needs_review の資料だけです。

1. needs_review を先に見る … 付議区分と結びの食い違いは、起案部門の書き違いか、付議区分そのものの変更かを確かめます。 後者なら一覧を直し、法務に知らせます
2. needs_fix の差し戻しの文を確かめる … 未着の別紙の番号、表紙の議案番号の違いが当たっているかを、資料を開いて見ます
3. 承認する … 文を直して承認すると、担当者へ送られます
4. 判定を覆したら記録する … 「別紙は本体に綴じ込み済み」など、選択肢から理由を選びます

事務局の3名は、会議ごとに担当を分けます。 承認の依頼が3名全員に飛ぶと、誰かが見るだろうと全員が後回しにします。議案の一覧のリストに会議ごとの事務局の担当者の列を持ち、承認の依頼はその人だけに送ります。 担当者が休みの日は、事務局のチャネルに同じ依頼を出して、ほかの2名が拾えるようにしておきます。

1番目は AI にも規則にも任せません。 付議区分を決議事項から報告事項に変えるかは、会社の取締役会規則に照らして法務と決めることです。

目標は、120件をならして1件3分です。 問題ありと出るのが3割前後という想定で、それを大きく超える月は、表紙の書き方の決まりが各部門に伝わっていません。

例外に対処する

7行目は、運用を始めてすぐに出てきます。 別紙を1つの PDF にまとめて出す部門は多く、その場合はライブラリの別紙の番号では突き合わせられません。 本体の中の見出しから別紙の番号を拾う指示を、プロンプトに足しておきます。

記録を残す

• 提出されたファイルの版と作成日時、置いた人
• プロンプトに渡した一覧の行と、返った JSON の全文
• 判定、未着の別紙の番号、事務局の承認と差し戻しの文
• 督促を送った日時と段階、送り先
• 判定を覆した記録と理由
• 会議ごとの、締切までに届いた割合と差し戻しの件数

督促の記録を残すのは、締切に遅れた理由を後から説明するためです。 「督促が届いていなかった」と言われたときに、いつ、誰に、どの段階の督促を送ったかを示せます。

ログは提出用のライブラリとは別のリストに置きます。 資料を消したり差し替えたりしても、確認と督促の記録は残ります。

会議ごとの割合は、部門ごとに見ます。 毎回同じ部門が締切の後に出しているなら、締切を部門の事情に合わせて見直すほうが早く解決します。