予定とメールを扱うAIを作って、権限と入力形式でつまずいた話

予定を確認して、メールを探して、必要ならタスクにする。普段いくつもの画面でやっていることを、会話から扱えるようにしたくて、個人用のAIアシスタントを作っています。

2026年7月には、GoogleのCalendar、Tasks、Drive、Gmail、Contacts、Docs、Sheetsを扱うツールを組み込みました。n8nとDiscordを使う構成です。つまずいたのは、AIの返答をどう書かせるかより、その先のAPIにつなぐ部分でした。

権限をコードに足しても、同意は更新されなかった

最初に困ったのがOAuthです。アプリに許す操作の範囲を表す「スコープ」を設定に追加しても、以前の同意で取得した認証情報には、その権限が増えていませんでした。

コードには使いたい権限が書いてある。なのにAPIからは拒否される。設定ファイルだけを見ていると、ここを見落とします。

必要だったのは、新しい範囲について同意を取り直すことでした。この経験から、接続を調べるときは「実装が要求する権限」と「実際に許可された権限」を分けて見るようになりました。ログインできたことと、目的の操作ができることも別です。

もう一つは、Geminiに渡すツールの入力定義です。配列であることを示すARRAYは書いていたのに、その中身の型を表すitemsが抜けていました。

その状態では、該当するツールを実行する前に、ツール定義を含むリクエスト自体が400で失敗しました。複数のツールをまとめて渡していたため、会話全体が止まって見えます。

自然言語での指示を直しても、この入力形式の不備は直りません。モデルに渡す定義を確認して、配列の要素まで型を書き足しました。AIの機能が増えるほど、会話だけを試すのでは原因を追いづらくなります。

Google APIを直接fetchしていた部分はgoogleapisへ移し、接続を確認するためのスクリプトも追加しました。認証とAPI呼び出しを単独で試せれば、問題が会話側にあるのか、接続側にあるのかを切り分けられます。

メールを読む操作と送る操作では、間違えたときの影響も違います。便利にするほど、どこまでAIに任せるかを明確にしたいです。送信のように相手へ影響する操作では、内容を確認する人の判断を残すつもりです。

なお、これは7月の実装を振り返った記事です。9月には開発環境をWindowsからMacへ移しており、移行後の再接続と起動確認は別の作業として残っています。ツールを書けたことと、普段の環境で使い続けられることの距離は、まだ埋めているところです。