社内からの自動化の相談を、効果と手間で仕分けて着手の順番を決める

処理の起点を決める

Google フォームが送信されたことを起点にします。 インストール可能なトリガーの「フォーム送信時」を使い、1件届くたびに動かします。

1日1回のまとめ処理にはしません。 着手は点数順ですが、台帳に載るのは早いほどよいからです。 載っていない相談は比較の対象にならず、その間だけ「声の大きさ」で決まります。

本構成では、回答の履歴がそのまま表として残るスプレッドシート側に付けます。あわせて時間主導のトリガーを1つだけ足し、週1回、未確認の上位を窓口へ通知します。

入力データを集める

質を決めるのは、上から2つです。 3つの数が入っていなければ点数が出ず、過去案件の一覧が無ければ実装の手間の目安が「勘」に戻ります。「来年も続くか」は後述の点数の式で使います。来年やめる業務を自動化するのは、作った瞬間に捨てるものを作ることです。

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

フォーム送信のトリガーが渡すイベントには、どちら側に付けたかで違う情報が入ります。

どちらで読むにせよ、位置で読まないでください。 values は列の並びそのもので、質問を1つ足しただけで、それ以降の値がすべてずれます。 FormResponse 側も同じで、getItemResponses() は「フォームに項目が表示されるのと同じ順序で」返しますが、テキスト、日付、時刻、段落の項目は未回答でも空文字が返る一方、それ以外の項目は未回答だと配列から除外されるとされています。配列の長さが回答ごとに変わります。 質問名をキーにする namedValues で引いてください。

相談者のメールアドレスは、設定を有効にしないと取れません。 getRespondentEmail() は「Form.setCollectEmail(collect) の設定が有効な場合にのみ機能する」とされています。理由を返す動線がこの記事の要なので、最初に確かめてください。

AIへ渡す前に整形する

1. 3つの数の確認 … 月に何件、1件何分、何人が入っているか。1つでも欠けていれば、そこで止めます
2. 数の範囲の確認 … 1件何分が0以下、480分より大きい、月に何件が0といった値は確認に回します
3. 重複の照合 … 同じ部署から同じ業務名の相談が過去90日にあれば、既存の相談に紐づけます
4. 説明文の整形 … 転記された署名、引用の記号、繰り返しの改行を落とします
5. 伏せ字化 … 個人名と取引先名を 【氏名】 【取引先】 に置き換えます
6. 長さの上限 … 長すぎる説明文は先頭の一定量に切り、切ったことを記録に残します

1番目を「警告を出して続行」にしないでください。 3つの数が欠けた相談を受理すると、点数の出ない行が台帳にたまります。点数の無い行は、結局また声の大きさで拾われます。 受理せず、聞き返しの下書きを返すところまでを自動で行い、相談の状態は「情報待ち」にします。

AIに処理させる

させるのは3つだけです。 相談内容の要約と分類、既存の仕組みで済むものの検出、実装の手間の目安とその根拠の提示です。

分類を7つに限っているのは、点数の式で使うためです。 分類ごとに「残る割合」を社内で固定するので、自由文だと当てはめられません。

上の2行が、この構成でいちばん大事な線引きです。 順番と点数をAIに出させると、その場では一覧が出来上がります。しかし基準を変えたくなったとき、何を変えればよいのかが分かりません。 式が外に出ていれば、直すのは式の1行です。

指示内容を固定する

あなたは情報システム部門で、各部署から届く「この作業を自動化したい」という
相談を仕分ける立場です。相談フォームの回答だけを見て整理してください。
着手の順番も、点数も、採否も決めないでください。

【やること】
1. 相談内容を3文以内に要約する。相談文に無いことを足さない。
2. 作業の種類を次の7つから1つ選ぶ。当てはまらない場合だけ other。
   shuukei（集計）／ tenki（転記）／ tsuuchi（通知）／ shounin（承認）／
   kensaku（検索）／ tenken（点検）／ sakusei（作成）
3.【社内の既存の仕組みの一覧】と照らし、既存の仕組みで済む可能性を判定し、
   似たものがあれば、その名称を candidate に1つだけ書く。
4. 自動化しないほうがよい理由に当たる記述があれば挙げる。
   - low_frequency ... 発生が月単位でない（年に数回しか起きない）
   - ending .......... 来年やめる、別システムに移行すると書かれている
   - legal_review .... 法令や社内規程で人が確認する必要があると書かれている
   相談文に書かれていないものを推測で挙げないこと。
5. 実装の手間を 0.5 ／ 2 ／ 5（人日）から選ぶ。
  【過去案件の一覧】にある似た案件の実績人日を根拠にする。

【厳守事項】
- 着手の順番を書かない。優先度、順位、おすすめ、至急などの語を使わない。
- 点数を計算しない。数値の掛け算をしない。
- volume_month（月に何件）、min_per_case（1件何分）、headcount（何人）は、
  相談者が書いた値をそのまま写す。多い・少ないの補正をしない。
  書かれていない場合は null とし、missing_fields にその項目名を入れる。
- 自動化した後に何分になるかを書かない。
- existing_solution.candidate は【社内の既存の仕組みの一覧】にある名称だけ
  から選ぶ。一覧に無い製品名やサービス名を出さない。
- 実装の手間は 0.5 ／ 2 ／ 5 のいずれか。中間の値を書かない。根拠にできる
  過去案件が無い場合は 2 とし、effort_basis に「該当なし」と書く。
- 相談者への返信文を書かない。
- evidence には、判断の根拠にした相談文の該当箇所を、要約せず原文のまま写す。

【相談フォームの回答】{form_response}
【社内の既存の仕組みの一覧】{existing_tools}
【過去案件の一覧】{past_projects}

「優先度、順位、おすすめ、至急などの語を使わない」まで書かないと、要約に混ざります。 相談文には「至急お願いします」「いちばん困っています」と書かれているので、何も言わなければ要約がその温度をそのまま運んできます。 温度を運ぶのは、式で順番を決める意味を消します。

「補正をしない」を2か所に書いているのも同じ理由です。 禁じるだけでは「実態は30件程度と推定される」と添えてきます。申告値と実測値が混ざると、裏取りの動線が意味を失います。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "request_id": "",
  "summary": "",
  "category": "shuukei | tenki | tsuuchi | shounin | kensaku | tenken | sakusei | other",
  "reported": {
    "volume_month": 0,
    "min_per_case": 0,
    "headcount": 0,
    "continues_next_year": "yes | no | unknown"
  },
  "missing_fields": ["volume_month"],
  "existing_solution": { "found": "yes | maybe | no", "candidate": "", "evidence": "" },
  "not_recommended": ["low_frequency"],
  "effort_days": 2,
  "effort_basis": "",
  "evidence": "",
  "needs_human": "yes | no"
}

この形を毎回そろえるために、構造化出力（Structured Outputs）を使います。 Claude API では output_config.format に type: "json_schema" とスキーマを渡すと、応答がそのスキーマに従うよう制約されます。1件でも形が崩れると、その行だけ点数が出ずに台帳から漏れます。

3行目を見落とさないでください。 「1件何分は480以下」といった範囲をスキーマで縛ることはできません。前処理で範囲を確かめているのは、このためです。

システムへ連携する

点数は Apps Script が計算します。社内で決めた固定の式を、スクリプトの中に1か所だけ書きます。

月間削減見込み（分）
  ＝ 現在の1件あたり分 × （1 － 残る割合） × 月間件数 × 対象人数

点数 ＝ 月間削減見込み（分） ／ 実装の手間（人日） × 継続係数

この式を、相談者が読める場所に置いてください。 社内のページに貼るだけで構いません。「なぜ自分の相談が後回しなのか」に答えられるのは、式が公開されているときだけです。

人が確認する

人が確かめるのは4つです。 台帳の全件ではありません。

1. 申告された時間の裏を取る … 点数の上位から、その週に着手を検討する数件だけ。似た業務の過去案件の実績人日と、対象システムの操作ログの件数を見ます。 申告の40件に対してログが12件なら、その差を相談者と確認します
2. 既存の仕組みの候補を確かめる … found が yes または maybe のものについて、その機能が本当に相談の内容を満たすかを人が触って確かめます
3. しないほうがよい相談を判断する … not_recommended が付いたものを開き、対象から外すか、継続係数を下げて残すかを決めます
4. 着手・保留・却下を決め、理由を返す … 定型文に、点数と式と理由を差し込んで返します

1番目の裏取りを省かないでください。 申告された時間は、多くの場合、実際より長くなります。 悪意ではなく、いちばん大変だった月の記憶で答えるからです。逆に実際のほうが多いこともあります。どちらに転んでも、数字が動いたことを台帳に残してください。

4番目が、いちばん軽く扱われがちで、いちばん効きます。 却下でも保留でも、理由を返さなければ、相談者から見れば無視と同じです。 無視された相談者は次から相談せず、相談が来なくなると、順番を決める材料そのものが枯れます。 保留なら現在の点数と上位の点数の目安を、却下なら理由の区分と代わりの手段を返します。

例外に対処する

いちばん下の行が、運用で崩れやすいところです。 「急ぎだからメールで送りました」を受け付けると、その1件は点数の付かない相談になります。窓口が代理で入れます。

記録を残す

• フォーム回答の原文と、送信のタイムスタンプ、相談者のメールアドレス
• AIに渡した内容（伏せ字化した後のもの）と、返ってきたJSONの全文
• そのとき使った分類の定義と、残る割合の表
• 点数の計算に使った値と計算結果。申告値と、裏を取った値を別の欄に持つ
• 人が判定を覆した記録と、却下・保留の理由、返した日時
• 着手したものについて、実際にかかった人日と、導入後に実測した1件あたり分

いちばん下の行が、四半期の見直しの材料そのものです。 着手したものについて本当に時間が減ったかを実測し、分類ごとに差を集計すると、残る割合の当たり外れが見えます。集計は四半期に一度だけにしてください。 毎月直すと式が落ち着かず、保留と返した相談者に「先月の説明」が通じなくなります。