生成AIを使った自動化は、APIキーを作れば始まるように見える。 けれど、最初に決めないまま連携を増やすと、どこで失敗したのかも、誰が投稿を確認するのかも分からなくなる。
Gemini API、Google Apps Script（GAS）、Chatworkを組み合わせるなら、コードを書く前に処理の境界を決めたほうがよい。 小さく始める目的は、すべてを自動化することではない。 人が繰り返している作業のうち、判断を伴わない部分だけを短くすることである。
先に「最後に何が届けばよいか」を決める#
「Chatwork botを作る」は、作るものの名前であって目的ではない。 たとえば、毎朝の問い合わせを短く要約して担当者へ渡す、会議メモから確認事項だけを残す、フォーム回答を読んで下書きを作る。 最後に届く情報が一文で説明できれば、必要な処理を絞れる。
処理の流れは、最初は次の四つで十分である。
入力を受け取る
→ Gemini APIで下書きを作る
→ 人が内容を確認する
→ Chatworkへ投稿するこの順番で始めると、生成結果をいきなり外部へ送らずに済む。 個人情報、誤った要約、社内に出してはいけない文言が混ざっても、投稿前に止められる。
GASは連携の中心を小さく保てる#
GASはGoogle Workspaceと近い場所で動かせるため、Google スプレッドシートやフォームから始める小さな連携と相性がよい。 ただし、GASへすべての判断を詰め込むと、後から変更しにくくなる。
最初は、入力を整える処理、Gemini APIを呼ぶ処理、Chatworkへ送る処理を分ける。 どこかが失敗したときに、原因を一つずつ確認できるからである。
function getSecret(name) {
const value = PropertiesService.getScriptProperties().getProperty(name);
if (!value) throw new Error(`${name} is not configured`);
return value;
}認証情報は、コードへ直接書かず、スクリプトプロパティなどの設定領域から読む。 この関数だけでは秘密情報を安全にするわけではないが、ソースコードをコピーしたときにキーまで広がる事故を減らせる。
APIキーは最初に置き場所を決める#
Gemini APIのキーは、Google AI Studioで作成し、環境変数や秘密情報の管理機能から参照する方法が案内されている。 Googleの公式ドキュメントは、キーをソースコードやクライアント側のアプリへ含めず、漏えい時には新しいキーへ切り替えて旧キーを無効化するよう説明している。
GASで試す場合も、共同編集者が見られる場所へキーを貼らない。 スクリプトを共有する範囲、キーを更新する担当、利用量を確認する場所を、作り始めに決める。 試作の段階でも、キーを使い回すほど原因の切り分けが難しくなる。
Chatworkも、APIトークンで外部プログラムからメッセージ送信やタスク追加を行える。 トークンを再発行すると以前のトークンは無効になるため、再発行時には連携先の設定をまとめて更新する必要がある。
自動投稿の前に、下書きで一週間使う#
最初から定時実行や自動投稿を設定すると、便利さより先に例外処理が増える。 入力が空だった日、要約が長すぎる日、宛先を間違えた日を、いきなり本番の部屋で経験することになる。
そこで、最初の一週間は手動実行と下書きだけにする。 入力を一つ選び、生成結果を別のシートや自分だけのChatworkルームへ出す。 次の三つを確認してから、定時実行や共有先への投稿を追加する。
- 入力に含めてはいけない情報が混ざっていないか。
- 生成結果を読んだ人が、次に何をすればよいか分かるか。
- 失敗したときに、誰がどの設定を止めるか分かるか。
生成AIは、同じ入力でも表現が揺れる。 その揺れを許せる業務から使い、正確な転記や金額計算のような処理は別の仕組みに任せる。
連携を増やす前に、削れる作業を一つ確認する#
小さな自動化が役に立ったかどうかは、連携サービスの数では測れない。 毎日十分かかっていた転記が一回減ったか、担当者が確認する項目を先に読めるようになったかで確かめる。
一つの流れが安定してから、入力元を増やすか、出力先を増やすかを選ぶ。 Gemini API、GAS、Chatworkの組み合わせは、完成したbotを一度に作るためのものではない。 人が判断に使う時間を残しながら、面倒な往復を一つずつ減らすための土台になる。
