中小企業診断士・ITコーディネータの大澤真介です。 資金繰り管理SaaS「GUULY」を運営する合同会社オンザウェイの代表をしています。
今回は、AIコーディングエージェント「Claude Code」と1日で自分専用のカレンダーBotを作った体験から、人間とAIの役割分担の実際を書きます。
私はこれまで、noteでGAS（Google Apps Script）を使った業務効率化の記事を何本か書いてきました。
バイブコーディングが話題になる中で、あえて中小企業・小規模企業が扱いやすいGASを推すスタンスで書いてきましたし、このアプローチは正しいと今でも思っています。
今後もその方向で書き続けるつもりです。
その上で、今回は少し毛色の違う話をします。
Claude Codeを筆頭に、AIコーディングエージェントが急速に広まっています。
私は普段のコーディングにはCursorを使っていて、特段Claude Codeに乗り換える必要性を感じていませんでした。
ただ、最近よく語られる「非エンジニアでも丸投げで開発できる」という体験を、自分でも一度ちゃんと味わっておきたかった。
そこで、自分の業務で実際に使うツールをClaude Codeと一緒に作ってみました。
LINEに「3月18日 15時から、京都経済センターでミーティングに参加」と送ると、Googleカレンダーの空き状況を確認し、前後の予定の場所から経路と乗り換え情報を調べ、移動時間も含めて予定を登録してくれるBotです。
開発期間は約1日（他のことをやりながら）。
総コード量は約4,200行。今回は意図的に、コードを1行も自分で書いていません。
Geminiでいいんじゃないの？という話
先に触れておきたいことがあります。
Googleカレンダーに自然言語で予定を登録すること自体は、GeminiなどのAIアシスタントでもできます。
「15時から京都経済センターで研修」と言えば、予定を作ってくれる。
ただ、実際に使ってみると、いくつか信用しきれない部分がありました。
まず、サブカレンダーの認識が曖昧です。私はGoogleカレンダーを相当細かく使い分けています。
「02_リアル確定」「01_オンラインMTG等」「04_仮押さえ」「03_移動」「05_バッファ」「06_集中タイム」といった用途別のサブカレンダーに加えて、同時進行している案件の一覧性を確保するためにプロジェクト単位・取引先単位・コミュニティ単位のサブカレンダーも存在します。
Geminiがこれらを正しく判定して適切なカレンダーに登録してくれるかというと、はっきりしません。
次に、動作が安定しない。同じような指示でも、うまくいく時といかない時がある。業務で日常的に使うツールとして、この不安定さは困ります。
そして最大の問題が、移動経路の検索と登録です。
前の予定の場所から次の場所まで、何時何分の電車に乗って、どこで乗り換えて、何時に着くのか。その移動時間を「03_移動」カレンダーに自動で登録する。
これはGeminiでは無理です。
できるかもしれませんが、正直、信用できません。
日本の公共交通機関の経路検索は専用APIを使わないと精度が出ない世界で、汎用のAIアシスタントに任せる領域ではないと判断しました。
だったら、自分の業務フローにぴったり合うものを自分で作ってしまおう。それがClaude Codeとの開発に踏み切った理由です。
人間がやったこと、Claude Codeがやったこと
今回の開発で最も印象的だったのは、コードの書き方を指示する必要がないということです。
「LINEで日時と場所を自然な文章で送ったら、Googleカレンダーに登録できるようにしたい。まず前後の予定を見せて、確認してから登録するフローで」
これだけで、Claude Codeはプログラミング言語の選定から設計、コーディング、サーバーへのデプロイまで一貫してやってくれました。
ただし、これは「AIに丸投げした」とは少し違います。
実はClaude Codeにコードを書かせる前に、SaaS版のClaude.aiで要件整理をしています。「こういう機能が欲しいんだけど、実現できる？」と相談するところから始めました。
各機能の実現可否、経路検索APIの選択肢とコスト比較、Phase分けの方針、マルチユーザー対応の設計判断—こうしたやり取りを経て、要件定義・技術仕様・データベース設計といったドキュメント一式を先に固めました。Claude Codeに渡したのはこの設計ドキュメントで、「これに従って実装して」と指示しています。
つまり、いきなりコードを書かせたのではなく、「何を作るか」を徹底的に言語化する工程が先にある。
この準備に半日くらい使いました。
その上で、私がやったのは「何を優先するか」の意思決定と、使うAPIの最終選定、コスト判断です。
Google Cloud PlatformやLINEの管理画面での設定作業も人間の仕事でした。
そして何より、実際にLINEから操作して「ここが使いにくい」「この表示は違う」とフィードバックすること。
「場所のデータを自動蓄積する仕組みにしよう」「先に登録している移動と重複しているときの動作は？」「前の予定、後の予定がない時は自宅を始点・終点に」といった設計レベルのアイデアを出すこと。
これらは全部、私の担当です。
一方、Claude Codeは21ファイル・約4,200行のコードを生成し、LINE・Googleカレンダー・Google Sheets・経路検索など6つの外部サービスとの連携を実装し、サーバーへのファイル転送から再起動、ログの確認まで行い、最終的には40箇所以上のエラー処理まで設計・実装してくれました。
Gitのコミットとプッシュもです。
私はGUULYを自分で開発している程度にはコードが書ける人間ですが、今回はあえてコードを書かなかった。
「非エンジニアの丸投げ体験」を再現するためでもありましたが、結果として実感したのは、コードを書かなくても、人間が判断し、決定し、フィードバックする仕事は山ほどあるということでした。
開発の実際：フィードバックの繰り返しが品質を作る
まず動くものを作り、使ってみて直す
最初の目標は「LINEで予定を送ったら、Googleカレンダーに登録できる」というシンプルなもの。数時間で動きました。
ここからが本番です。実際に使ってみると、次々と改善点が見つかります。
「カレンダーの種別しか変更できないのは不便。時間も場所もやり取りの中で修正できるようにして」
「カレンダーのURLがそのまま表示されてダサい。スマホのカレンダーアプリで直接開けるボタンにして」
こうしたフィードバックを伝えるたびに、数分で修正が反映されます。
修正→テスト→フィードバック→修正のサイクルがとにかく速い。
経路検索が最大の難所
2日目に取り組んだのが、公共交通機関の経路検索。
ここが最も議論と修正が多かった箇所でした。
前述のとおり、Google Directions APIは日本の電車・バスにまともに対応していません。
Claude Codeに代替案のコスト比較を依頼したところ、NAVITIME（RapidAPI経由、無料枠月500リクエスト）、駅すぱあとAPI（月額3万円〜）、Yahoo!乗換案内API（提供終了）、Google Routes API（日本の公共交通機関に非対応）の4つが出てきました。
ここは迷いました。
精度で言えば駅すぱあとが圧倒的です。
でも月額3万円を最初から払うのは、個人で使うツールとしてはバランスが悪い。
NAVITIMEの無料枠は月500リクエストで、私が1日に登録する予定は多くて5〜6件。
往路・復路で2倍としても月300リクエスト程度に収まる計算です。
「まずNAVITIMEで始めて、無料枠では足りなくなったら、その後考える」と判断しました。
※今回は作っていませんが、交通費の精算も楽にしたいので、ゆくゆくは連動させたいと思っています。そうなると代案を検討する必要があります。
こういうランニングコストと利用頻度を天秤にかけるビジネス判断は、AIにはできません。
Claude Codeは4つの選択肢を正確に並べてくれましたが、「どれにするか」は私が決める仕事です。
経路検索を実装した後が、さらに泥臭いやり取りの連続でした。
最初に出てきた経路表示は「移動時間：約40分」とだけ書かれたものでした。これでは使い物になりません。
「何時何分の電車に乗って、どこで乗り換えるのか知りたい」と伝えて、時刻表ベースの詳細ステップ表示に作り直させました。
次に引っかかったのが出発時刻の問題です。
前の予定が16時終了で、最寄り駅まで徒歩7分。
なのに案内される電車は16時37分発。30分も何をして待つのか。
原因を調べると、出発時刻に余裕を持たせすぎるロジックになっていました。
前後の予定の場所とバッファ時間を反映して、もっとタイトに計算するよう修正。このあたりは「自分の行動パターン」を知っている本人でないと、適切なバッファが何分なのか判断できません。
移動イベントの登録条件も、何度かやり取りして詰めていきました。
最初の実装では、すべての予定に対して往路・復路の移動イベントを登録しようとしていた。
でも実際に使ってみると、同じビル内の会議室を移動するだけの場合や、徒歩3分の場所への移動にまで「03_移動」カレンダーにイベントが入ってしまう。
カレンダーが移動だらけになって、かえって見づらい。
「公共交通機関を使う場合は登録。使わない場合は、徒歩5分を超える場合だけ登録」。
このルールにたどり着くまでに、3回くらいやり取りしました。
さらに、次の予定が同じ場所の場合は復路の移動イベントを作らない、というロジックも追加。
これも実際にテストして「復路の出発地と到着地が同じ座標になっている」という不具合を見つけて、初めて気づいた問題です。
前回の記事で「技術的にできることを、あえてやらなかった」と書きましたが、今回は逆です。
「使ってみて初めてわかる不要な機能」を削っていく作業。
全部入りで作ってから、実際の運用に合わせて条件を絞り込んでいく。
この「引き算の設計」は、AIが自発的にやってくれるものではありません。
壊れにくくする
最後に取り組んだのがエラーハンドリングの強化です。
Claude Codeにコード全体を分析させたところ、40箇所以上の「エラーが起きたらそのまま止まる」部分が見つかりました。
通信エラー時の自動再試行、APIの利用制限に引っかかった時の対応、わかりやすいエラーメッセージの表示。
こうした「地味だけど実運用に不可欠な処理」を10ステップにまとめて一括実装しました。
GASとAIエージェント、どっちがいいの？
私の答えはシンプルで、両方使えばいい。それだけです。
私はこれまでの記事で「バイブコーディング時代だからこそ、小さな会社はGASから始めるべき」「GAS×生成AIが引き継ぎ戦略になる」と書いてきました。この考えは今回の体験を経ても変わりません。
GASの良さは明確です。
無料で始められる、Googleの環境をそのまま使える、どの生成AIでも無料版でも充分なコードを書いてもらえる。
小さな会社がスプレッドシートの転記を自動化したり、フォームの回答を集約したりするには、GASが最適解であることに変わりありません。
一方、今回のカレンダーBotのように、6つの外部APIと連携し、自然言語を解析し、状態管理を伴う対話フローを持ち、サーバー上で常時稼働するようなツールは、GASの守備範囲を超えています。
こういう領域はAIコーディングエージェントの出番です。
そして面白いのは、今回のツールでも、設定情報の管理にはGoogleスプレッドシートを使っているということ。
カレンダーの種別ルール、サブカレンダーのIDリスト、場所データベース。これらはすべてスプレッドシートに持たせて、プログラムから読み込む設計にしました。
理由は単純で、見やすいし、変更もしやすいからです。
GASかAIエージェントかという二択ではない。得意な部分を組み合わせる。 スプレッドシートの集計を自動化するならGAS。
複数のサービスを横断する自分専用ツールを作るならAIエージェント。
そして設定やマスタデータの管理にはスプレッドシート。
適材適所です。
この体験で確信したこと
世の中にはカレンダー管理のアプリやサービスがたくさんあります。
でも、「関西圏の公共交通機関に対応」「用途別・プロジェクト別のサブカレンダーを自動判定」「前後の予定の場所から移動経路を検索して移動イベントも自動登録」「LINEから操作」という、私の業務にぴったりのツールは市販されていません。
かつてなら、こういう「自分にしか需要がないツール」を作るには、プロのエンジニアに数十万円で発注するか、自分でプログラミングを学ぶかしかなかった。
私がGUULYを作った時は、プログラミングをイチから学んでリリースまで1年半かかりました。
AIコーディングエージェントは、この状況を変えつつあります。
鍵になるのは、「こう動いてほしい」を言語化する力です。
「誰でもできる」は、現段階では嘘だと思います。
でも、そんなにハードルが高いわけでもない。
今回の開発を振り返って思うのは、AIエージェントに的確に要望を伝え、出てきたものにフィードバックし、優先順位を判断する—この一連の動きは、プログラミングの知識とは別の能力だと感じました。
むしろ、ITがそれほど得意でなくても、実際のビジネスの場で部下やチームのマネジメントをやってきた人なら、すでにその素養を持っていると私は思います。
「こういう結果がほしい」とゴールを示し、上がってきたアウトプットに「ここが違う」「こっちを優先して」とフィードバックし、全体の方向性を判断する。
AIエージェントとの協働は、この仕事の進め方にかなり近い。
私と同世代、あるいはもう少し上の世代の経営者の中には、「AIやプログラミングは若い人のもの」と感じている方もいるかもしれません。
でも、長年の業務で培ってきた「何をどう伝えれば人が動くか」という感覚は、そのままAIエージェントにも通用します。
自分の業務を一番よく知っている自分が、AIの力を借りて自分専用のツールを作る。
この体験は、思っていたよりずっと地に足のついたものでした。
最後までお読みいただきありがとうございました。 中小企業のIT活用・生成AI活用について、引き続き発信していきます。
この記事はnoteでも公開しています。
実装支援・DX推進・生成AI活用のご相談は、お気軽にお問い合わせください。
→ お問い合わせはこちらから