この記事は 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）