Anthropic の Claude Agent SDK は、AI エージェントを構築するための公式ライブラリで、Python と TypeScript の両方で提供されています。この記事では、Claude Agent SDK と Google Sheets API を組み合わせて IT 申請フォームの選択肢を動的に更新する設計パターンを、情シス担当者の実務視点で整理します。
この記事を読んだほうが良い人
- Google フォームや Sheets の選択肢を毎月手作業で更新していて、仕組み化を検討している情シス担当者
- Claude API を使った業務自動化に興味はあるが、どの設計パターンから始めればよいか迷っている方
- GAS（Google Apps Script）での実装が複雑化してきて、設計を見直したい方
Claude Agent SDK とは何か
Claude Agent SDK は、Claude を中核に持つ AI エージェントを構築するための Anthropic 公式ライブラリです。ツール呼び出し、サブエージェント、セッション管理、MCP（Model Context Protocol）クライアントなど、複数の機能を標準で備えています。
通常の Claude API 呼び出しはプロンプトを送って回答を受け取る一問一答の形です。Claude Agent SDK はその一歩先で、エージェントが「どのツールをどの順番で呼ぶか」を状況に応じて動的に判断しながら処理を進めます。たとえば「承認済みソフトウェア一覧を Sheets から読み込み → フォームの選択肢データを更新 → 申請内容を別のシートに書き込み → 承認者に通知する」という一連の処理を、複数のツール定義をもとにエージェントが自律的に組み立てます。
GAS でも同様の処理は書けますが、分岐や条件が増えるほど if/else が肥大化します。Claude Agent SDK では「何をすべきか」をエージェントが判断するため、処理フローを全部書き切るより、ツールの定義に注力できる設計になります。情シスが設計すべきは「処理の順番」ではなく「ツールの責任範囲」という点が、発想の切り替えポイントです。
ライブラリは Python と TypeScript の両方で提供されており、Google Cloud Functions や Cloud Run との組み合わせでサーバーレス実行することも可能です。GWS 環境でどちらのランタイムを選ぶかは、既存インフラや社内メンバーのスキルセットに合わせて判断します。GAS エコシステムに慣れているチームであれば、TypeScript/Node.js ベースのほうが学習コストを抑えやすい場面があります。
Claude Agent SDK Google Sheets 自動化の設計パターン
Sheets との連携は、トリガー・ツール・出力の 3 レイヤーで考えると整理しやすいです。
トリガー層：いつエージェントを起動するか
代表的なパターンは 2 種類あります。
- スケジュール実行: 毎朝定時に Sheets のマスターデータを参照し、フォームの選択肢を自動更新する
- リクエスト起動: 申請フォームの送信をトリガーに、Sheets への書き込みと承認通知を一括で実行する
スケジュール実行は Google Cloud Scheduler から HTTP リクエストでエージェントを起動する構成が扱いやすいです。GAS の時間ベーストリガーからエージェントの API エンドポイントを呼ぶ構成でも動作しますが、GAS の実行タイムアウト（最大 6 分）に注意が必要です。処理が長引く可能性があるなら Cloud Scheduler ＋ Cloud Functions の組み合わせの方が安全です。リクエスト起動の場合は、Google フォームの送信時に走る GAS スクリプトからエンドポイントを呼ぶパターンが一般的です。
どちらのパターンでも、エージェントの起動ロジックと処理ロジックは分けて管理します。起動の仕組みが変わっても（スケジュール変更や別のトリガーへの切り替えなど）、ツール定義には手を入れずに済むため、後からの改修が楽になります。
ツール層：エージェントが呼べる「作業単位」を定義する
ツールはできるだけ単一責任で定義するのが原則です。後から機能を追加・変更したときの影響範囲を限定できます。
下記は概念的なツール定義の構造例です。実際の Sheets API の呼び出し詳細は公式リファレンスを参照してください。
# ツール定義の概念例（Python）
# 実際の API 呼び出し詳細は公式ドキュメントを参照
def get_approved_software_list() -> list[str]:
"""承認済みソフトウェア一覧をマスターシートから取得する"""
# Sheets API でマスターシートのデータ範囲を読み取り、
# ソフトウェア名のリストを返す
...
def write_request_log(applicant: str, item: str, date: str) -> bool:
"""申請内容をログシートに1行追記する"""
# Sheets API で申請ログシートの末尾に行を追加する
...
def notify_approver(approver_email: str, summary: str) -> bool:
"""承認者へ申請サマリーをメールまたは Slack で通知する"""
# Gmail API または Slack Webhook を呼び出す
...
エージェントはこれらのツールを「今何が必要か」という文脈に基づいて自律的に呼び出します。「〇〇ソフトの申請が届きました」という入力を受けたエージェントが、まず get_approved_software_list でリストを確認し、申請内容が一覧に含まれるかを判断したうえで write_request_log で記録し、最後に notify_approver で通知する、という処理を自動で組み立てます。
GAS では処理順序をすべてコードで書き切る必要がありましたが、SDK ではツールの定義さえ整っていればエージェントが判断します。ツールが細かく分かれているほど、エージェントは状況に応じた組み合わせを選べます。一方で、ツールが増えすぎるとエージェントの判断コストが上がり（処理時間の増大・API コストの増加）、デバッグも難しくなります。初期フェーズでは 5〜7 個程度のツールから始め、動作を確認しながら追加していくのが現実的です。
出力層：エージェントが生成するもの
ツールの実行結果として生成される代表的なアウトプットは以下のとおりです。
- Sheets の特定セル範囲の更新（フォームのドロップダウン選択肢のマスターとして使う）
- 申請ログシートへの追記（誰が・いつ・何を申請したかの記録）
- 別ツールと組み合わせた Slack や Gmail への通知
- エージェントの実行ログ（どのツールを・いつ・どのデータで実行したかの記録）
出力先が Sheets だけに限定されない点がこの設計の強みです。「Sheets のデータを読んで、Slack に投稿して、ログを Sheets に書く」という複合的な処理も、ツールを組み合わせるだけで対応できます。
業務フォーム自動化のユースケース例
情シスが日常的に直面する申請フォーム管理に絞って、3 つのユースケースを示します。
IT 資産申請フォームの選択肢自動更新
情シスが管理する端末マスターシート（型番・在庫数・割当部署などを記録）をデータソースとして使い、申請フォームの「希望機種」ドロップダウンを定期的に自動更新します。在庫が 0 になった機種は選択肢から自動除外され、新機種を追加したらフォームに即座に反映されます。毎月手動でフォームを編集する作業がなくなるのは、小規模情シスには特に実感しやすいメリットです。
運用上のポイントとして、マスターシートに「公開対象フラグ」列を用意しておくと便利です。在庫 0 でも「近日入荷予定」として選択肢に残したい場合、フラグをエージェントに読み込ませて出し分けを判断させられます。フラグの値を変えるだけでフォームの表示が変わる設計にしておくと、情シス側の操作コストが下がります。
ソフトウェア調達申請
「承認済みソフトウェア一覧」を管理する Sheets を読み取り、申請フォームの選択肢を動的生成します。申請が提出されると、申請者情報・申請日・承認状況を「申請ログ」シートに自動記録します。承認者は Sheets を確認するだけで対応待ち件数を把握できる状態になります。
このユースケースで特に重要なのはスキーマ設計です。申請ログシートの列（申請者・メールアドレス・申請日・ソフトウェア名・承認者・承認日・ステータスなど）を実装前に確定させないと、後からエージェント側のツール定義も変更しなければならなくなります。チームで列構造を合意してからツール定義に入ることが前提です。
外部ベンダーアクセス申請
申請者のメールアドレスを受け取ったエージェントが社員マスターシートを照合し、所属部署・上長・入社日を自動補完してから申請ログに書き込みます。手入力ミスを抑えつつ、情シスが後から監査しやすいログ形式を維持できます。外部ベンダーへのアクセス権付与は監査証跡が重要なため、誰が・いつ・どの権限を申請したかを Sheets に継続的に記録する設計が、監査時の根拠として機能します。
OAuth スコープと権限最小化の考え方
Claude Agent SDK から Sheets API を呼び出す際は、OAuth スコープ（アクセス権の範囲）を必要最小限に絞ることが原則です。
判断の基本は「ツールごとにスコープを分けて考える」ことです。
- シートを読むだけのツールであれば、読み取り専用スコープで十分です
- シートに書き込むツールでは書き込みスコープが必要ですが、アクセス対象のスプレッドシートを特定のファイルに限定できるかを事前に確認します
権限設計でよくある失敗は「とりあえず広めのスコープを付与する」ことです。Drive 全体への書き込み権限を付与すると、ツールのバグや想定外のエージェント動作があったとき、意図しないファイルが上書きされるリスクが生じます。マスターシートと申請ログシートのみをサービスアカウントと共有する構成にしておけば、影響範囲が明確になります。
認証方式は、エージェントを自動実行するならサービスアカウントが一般的です。サービスアカウントには必要な Sheets だけを共有し、Google Drive 全体への権限は付与しないことを前提とします。
Claude Agent SDK では、エージェントが実行時にどのツールを呼ぶかは動的に変わります。そのため「定義したツール以外はアクセスできない設計」にしておくことが、GAS よりも重要になります。ツールとスコープのセットを 1 対 1 で管理するイメージで整理すると、後から権限のレビューがしやすくなります。
加えて、サービスアカウントの認証情報（キーファイル）の管理にも注意が必要です。GitHub リポジトリや GAS スクリプト内にキーをハードコードするのは禁止として、Google Cloud の Secret Manager や環境変数として注入する設計を採用します。認証情報が漏洩した場合のローテーション手順もあらかじめ決めておくと、インシデント対応がスムーズになります。
実装前に確認すべき 4 つのポイント
実際に連携を組む前に、以下の 4 点を整理しておくと手戻りが少なくなります。
1. マスターシートの管理主体を決める
エージェントが参照する Sheets のオーナーと更新担当者を最初に明確にします。「誰でも編集できる」状態は、不正なデータがエージェントに流れ込むリスク要因です。最低でも編集者と閲覧者のロールを分け、マスターデータの更新権限は絞っておきます。エージェントが使うサービスアカウントには閲覧権限のみを付与し、書き込み権限は申請ログ専用シートに限定するのが基本構成です。
2. スキーマ（列定義）を先に固める
エージェントが読み書きするシートの列構造は、実装前に確定させます。後から列を追加・移動するとツールのロジックが壊れるため、列名と列順をチームで合意してから連携設計に入ることが前提です。バージョン 1 では最小限の列だけ定義し、後から列を追加する場合はツール定義も同時にレビューするルールを設けておくと安全です。
3. エラーケースの挙動を決める
対象の Sheets が一時的に取得できないとき、エージェントがどう振る舞うかを事前に決めておきます。「エラーとして申請を止める」「前回のキャッシュ値を使う」「デフォルト選択肢で動かす」のどれを選ぶかは業務要件次第です。設計段階でエラーシナリオを書き出し、エラー時の通知先（情シスへのアラートなど）も含めて合意しておくと、実装時の仕様揺れが減ります。
4. エージェントの操作ログを残す
エージェントが何を読み取り、何を書き込んだかの記録は、後から監査・デバッグに欠かせません。「いつ・どのツールを・どのシートに対して実行したか」はログに残す設計にします。既存の GWS インフラに合わせて、Google Cloud のロギングサービスや Sheets 自体へのログタブ追加などを検討します。エラーが発生したときのトラブルシューティングにもログが不可欠なため、動作確認の段階から記録の仕組みを組み込んでおくのが安全です。
GAS と Claude Agent SDK：どちらを選ぶか
GAS と Claude Agent SDK は「Sheets を自動化する」という目的では重なりますが、得意な場面が異なります。
| 条件 | 選択の目安 |
|---|---|
| 処理フローが固定で変わらない | GAS |
| 申請内容に応じて判断・分岐が多い | Claude Agent SDK |
| 既存の GAS スクリプトを活かしたい | GAS を基盤に Claude API を補助的に使う |
| エージェントにツールを自律的に選ばせたい | Claude Agent SDK |
| チームに JavaScript/TypeScript の知識がある | GAS or TypeScript 版 SDK どちらも選択肢になる |
「GAS で書いたら if/else だらけになってメンテナンスが大変」という経験があれば、Claude Agent SDK でツールを定義してエージェントに判断を委ねる構成を検討する余地があります。逆に処理が単純で GAS で事足りるなら、新たに SDK を導入するコストを正当化しにくい場面も多いです。
コスト面では、Claude Agent SDK は Claude API の呼び出しコストが発生します。1 回の申請処理で複数のツールを呼ぶ場合、API コールが増えるほどコストが積み上がります。GAS は基本的に Google Workspace の利用料金の範囲で動くため、呼び出し回数が多い処理では GAS の方がコスト効率が高い場面があります。月間申請件数と 1 件あたりの処理ステップ数を見積もってからアーキテクチャを決める手順を踏むのが現実的です。
規模感でいえば、月 1 回程度の定期更新であれば GAS で十分です。申請の種類が増えてきたり、フォームの選択肢ロジックが複雑化してきたタイミングが、Claude Agent SDK への移行を現実的に検討する分岐点になります。
設計の出発点は「ツールを小さく保つ」こと
Claude Agent SDK × Google Sheets の設計では、トリガー・ツール・出力の 3 レイヤーを分離し、ツールを単一責任で定義することが起点です。OAuth スコープをツール単位で考えて権限を最小化し、マスターシートのスキーマを先に固めてから実装に入ると、後から修正が必要になる場面を大きく減らせます。
まず小さなユースケース（端末マスターシートを読んでフォームの選択肢を更新するだけ）から試して、エージェントが自律的に動く感触をつかんでから範囲を広げていくのが安全な進め方です。GAS で実装していた処理を段階的に移行する場合は、最初の 1〜2 ツールを SDK に移してしばらく並行運用し、動作を確認してから次のツールを追加するフローが手戻りを抑えます。
Claude + GWS の実装設計については、DRASENAS でも相談を受け付けています。
コーポレートITのご相談はお気軽に
この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。
「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。
※ この記事は DRASENAS Blog の転載です。オリジナルではコードや設定手順が随時アップデートされています。