研修の開催予定を確認し、参加者を集計する表を用意して、当日の説明資料へのリンクをまとめる。研修事業の運営担当者には、一回の開催準備でカレンダー、表計算、ファイルの保管場所を行き来する仕事があります。こうした作業を一つの手順にまとめる道具として、Google Workspace CLI（gws）という公開プロジェクトがあります。
発表元の公開リポジトリによると、gwsはDrive、Gmail、Calendar、SheetsなどのAPIをコマンドで扱います。APIはソフトウェアからサービスの機能を使うための窓口、CLIは文字の命令で操作する仕組みです。画面上で行う確認や転記を、プログラムから呼び出す処理として組み立てる足場になります。
開催予定と参加者表をつなぎ、準備の下書きを作る
gwsは、Google Discovery Serviceが提供する情報から操作を組み立て、結果をJSONで返すと説明されています。JSONは項目名と値を整理して表すデータ形式です。プログラムが結果を読み取りやすいため、あるサービスで得た情報を次の処理に渡す設計が考えられます。AIが作業を進める際の手順をまとめた、エージェント向けのSkillsも含まれています。
たとえば研修事業なら、Calendarの開催予定、Sheetsの参加者一覧、Driveの説明資料を入力にする手順が考えられます。対象の研修を予定から選び、参加者一覧をもとに集計表の下書きを準備し、対応する説明資料のリンクを運営メモにまとめる流れです。これは想定する使い方であり、実際の導入事例や、そのまま使える完成済みの標準機能を示すものではありません。
減らせそうなのは、サービスを開くたびに同じ研修を探し直し、日付や名前を転記する作業です。ただし、同じ研修名で開催回が複数あれば、名前だけで結び付けると取り違えるおそれがあります。開催日や管理番号など、予定と参加者表を対応させる手掛かりを先に決めておく必要があります。
担当者の仕事も、転記した内容を一つずつ見直す作業から、どの情報を結び付けるか決め、出来上がった下書きを確かめる作業へ移せる可能性があります。コマンドで操作できても、業務上の正しい組み合わせまで自動的に決まるわけではありません。
読み取りと下書きから試し、送信前に人が確かめる
最初の試行は、予定の読み取り、集計表の下書き、資料リンクの整理までを区切りにすると、結果を確かめやすいでしょう。受講者への送信に進む場合は、対象の開催回、宛先、資料の版、共有範囲を人が確認する工程を置く設計が考えられます。一回分の研修で試せば、どこまでを機械に任せ、どこで担当者の判断を挟むかを具体的に検討できます。
アクセス権も、その手順を設計する際の前提です。複数のサービスを扱えることを、全社の資料を自由に読めるという意味で捉えず、本人や組織が認可した範囲で、必要な予定や資料にアクセスできるかを確認します。また、説明資料のリンクを取得できることと、受講者がその資料を開けることは別に確かめる必要があります。
開発中の道具として、変更後の確認まで決めておく
公開リポジトリのREADMEは、gwsがGoogleによる公式サポート対象の製品ではないことを明記しています。開発中で、既存の処理が動かなくなるような破壊的な変更がありうるとされ、ライセンスはApache 2.0です。
この位置付けを踏まえると、研修当日の進行に直結する処理へ広げる前に、開催準備の一部で試し、変更時に誰が動作を確認するかを決めておくのが現実的です。予定、参加者表、説明資料を順番に扱う処理と、その途中に置く確認工程をセットで考えることで、gwsを任せられる範囲が見えてきます。