この記事は Zenn に投稿したものの再掲です。
https://zenn.dev/reona777/articles/six-tools-with-claude-code
教育系の事業所で現場の運営をしています。エンジニアではありません。コードを書くのは仕事ではないし、実務経験もありません。
2026年の春に Claude Code を使い始めて、5か月で社内ツールを6本作りました。全部を本番に出して、今も毎日動いています。
この記事は「AIですごいものが作れた」という話ではありません。動くものを作るところまではAIがやってくれます。問題はそこからで、本番で動き続けるものにするには人間側にやることが残る、という話です。その「やること」が何だったかを書きます。
作ったもの
数字は導入前の手作業を実測または見積もったものです。
入退室の自動記録・通知
利用者の入退室をLINEで受けて、Slackへ自動で記録します。1日60〜100通が自動で流れます。以前は目視と手入力でした。
予定リマインドの自動送信
Salesforceに入っている翌日の予定を読んで、対象者へ自動で通知します。1日20〜30件、月あたり約10時間の手作業が消えました。
予定の振替処理
振替の申請を受けてSalesforce側のレコードを書き換えます。1件あたり3〜5分かかっていた作業が月20〜50件あり、それがゼロになりました。
スタッフの空き時間カレンダー
縦にスタッフ、横に時間を並べたマトリクスで、空いている人を一目で判断できます。Salesforceからは読み取りのみ。Next.js + Vercel + Upstash Redis。
スクレイピングによる差分同期
Playwrightで外部サイトから取ってきた情報を、スプレッドシートへ差分だけ反映します。
LINE公式アカウントのAI自動応答（RAG）
よくある問い合わせに自動で答えるボット。これは運用の都合で現在は停止しています。
使ったのは Google Apps Script、Salesforce の REST API と SOQL、LINE Messaging API、Slack API、Next.js、Vercel、Upstash Redis、Playwright、GitHub Actions あたりです。並べると多く見えますが、どれも「この業務を自動化するには何が要るか」を追いかけた結果そこに辿り着いただけで、先に技術を選んだことは一度もありません。
なぜ動き続けるものになったか
ここからが本題です。4つあります。
1. 自分が毎日困っている業務しか作らなかった
6本とも、私自身が手でやっていて面倒だと思っていた作業です。これは想像以上に効きます。
理由は仕様を人に聞かなくていいからです。「この場合はどうするんですか」という質問が出るたびに、自分の中に答えがあります。エッジケースも全部知っています。誰かのために作ると、この確認のたびに数日止まります。
そしてもうひとつ、壊れたことに自分が最初に気づきます。通知が来ない日があれば、困るのは自分です。
逆に言うと、「便利そうだから作ろう」で始めたものは1つもありません。作りたくなったものは何度もありましたが、自分が毎日使わないものは、動かなくなっても気づかないまま放置されます。
2. コードより先に「言葉」を決めさせた
これが一番効きました。
AIにいきなり「〇〇を作って」と言うと、それらしいものが出てきます。動くこともあります。ただ、機能を足していくと途中で必ず破綻します。同じものを別の名前で呼び始めるからです。
たとえば私が個人用に作った学習記録アプリでは、「問」「項目」「単元」という似た概念があります。ここを曖昧にしたまま進めると、ある関数では「項目」が単元を指し、別の関数では設問を指す、という状態になります。そうなってから直すのは、書き直すのとほぼ同じコストです。
なので、実装の前に用語集を書かせるようにしました。
CONTEXT.md 用語の定義だけ。実装のことは書かない
SPEC.md 仕様。何がどう振る舞うか
docs/adr/ 「なぜそうしたか」を1決定1ファイルで残す
そのアプリでは、用語29語・仕様13節・ADR 6本になりました。この3つを先に書いてから実装に入ると、セッションをまたいでも、機能を足しても、言葉がぶれません。 AIは毎回コンテキストがリセットされますが、ファイルに書いてあれば読み直させられます。
書かせ方も重要です。私は「作って」ではなく「まず質問して」と言うようにしています。曖昧な指示に対してAIは黙って解釈を1つ選びますが、質問させると、自分でも決めていなかった部分がその場で見つかります。
3. 判断を純関数に追い出した
「この枠は空いているか」「次の復習日はいつか」といった判断のロジックを、UIからもデータベースからも切り離した関数に寄せました。
こうすると、画面を開かなくても保存先に繋がなくてもテストできます。学習記録アプリでは、この方針でテストが308件になりました。
非エンジニアにとってのメリットは、自分がコードを読めなくても正しさを確認できることです。「6か月ごとに回り続ける印が付いた問題は、最上段で最高評価を取っても卒業しない」という仕様が守られているかどうかは、テストが通るかどうかで分かります。私はロジックを目で追って検証する能力がないので、ここは代替手段として必須でした。
4. 本番で壊れる前提で作った
作った直後は全部動きます。壊れるのは1か月後です。
実際に踏んだものをいくつか挙げます。
GASの排他ロックの中でスプレッドシートを触っていた。 転送処理が、エラーも出さずに無言で届かなくなりました。ロックの中でシートのI/Oをすると詰まります。キャッシュサービス経由に変えて解決しました。
Vercelの関数リージョンが既定のまま（米国東部）だった。 データの保存先は東京に置いていたので、記録1回ごとに太平洋を3往復していました。東京リージョンに変えたら、体感で明らかに速くなり、実測で0.4秒前後から0.1秒前後になりました。
トリガーを作る関数を、自分でトリガーに登録していた。 起動のたびにトリガーが増殖します。
こういうものは、設計の段階では絶対に出てきません。本番に出して、1か月使って、初めて出てきます。 だから「作って終わり」にせず、動かし続ける前提で持ち物を減らすことが大事でした。6本という数字は、私が運用を見ていられる上限です。
うまくいかなかったこと
正直に書きます。
権限を確認せずに作って、一度も動かせなかったスクリプトがあります。 集計を自動更新するものを書いたのですが、更新先のシートに保護がかかっていて、その保護の所有者が別のアカウントでした。私が実行に使っているアカウントでは解除できません。コードは完成していて、テストも通っていて、動かせません。
何を作るかを考えるときに、それを動かす権限が自分にあるかを一緒に考えていませんでした。 業務ツールでは、技術的に可能かどうかより、権限的に可能かどうかで詰まることの方が多いです。AIは権限の話を先回りしては教えてくれません。作る前に「これは誰の権限で動くのか」を確認する癖がついたのは、この失敗からです。
公開用のコピーを別に作ったら、二重管理になりました。 作品としてコードを出すために、固有名を抜いたコピーを別リポジトリに作りました。結果、本体を直すたびに手でもう一方にも入れる必要があり、片方だけ古いという状態が起きます。分けるなら、分けたあとのコストまで最初に見積もるべきでした。
最初の頃はドキュメントを書かせていませんでした。 上に書いた用語集の話は、最初からやっていたわけではありません。破綻を1回やってから導入しました。
この記事で言いたかったこと
「AIにコードを書かせる」より、「AIに設計を言葉にさせる」方が効きます。
コードを書くのは、今のAIにとって一番簡単な部分です。難しいのは、何を作るかを曖昧さなく決めることと、それを1か月後の自分とAIに伝え続けることです。そこは人間側の仕事として残っていて、非エンジニアでもできます。というより、業務を一番よく知っているのは現場の人間なので、そこは現場の人間の方が向いています。
次に書くこと
この記事では触りだけにした2つを、別記事で詳しく書きます。
- AIに作らせたツールが本番で壊れた5つの原因と、直し方
- Claude Codeに CONTEXT.md と SPEC.md と ADR を書かせると、途中で破綻しなくなる
この記事で挙げた6本のうち5本は GitHub で公開しています。
-
line-slack-attendance— 入退室の自動記録・通知（GAS） -
lesson-reminder— 予定リマインドの自動送信（Python） -
salesforce-lesson-reschedule— 予定の振替処理（Python） -
playwright-spreadsheet-sync— スクレイピングによる差分同期（Python） -
teacher-availability-calendar— スタッフの空き時間カレンダー（TypeScript / Next.js）