「AIを使えば、エンジニアでなくても業務システムを作れる」。そんな話を聞く機会が、ずいぶん増えました。

僕も、サポートに入っている会社の業務を楽にしようと、Claude Code（AIのClaudeに、プログラムを書いたり動かしたりしてもらえる開発ツール）を使って勤怠のシステムを作りました。紙の勤怠カードをAIで読み取り、Excelの勤務記録表を作るものです。本番のサーバーで動くところまで作り込みました。

でも、結果は「見送り」でした。

先に結論を書くと、「作れること」と「使ってもらえること」は、まったく別の問題でした。AIが一気に楽にしてくれたのは、前者だけです。この記事では、何を作り、なぜ導入されなかったのか、そこから何が見えたのかを書きます。

正直に言うと、見送りについては半分は納得していて、半分は納得できていません。

作ったもの：紙の勤怠カードを読み取って、勤務記録表を作るシステム

きっかけは、月末の20分の打ち込み作業

その会社では、紙の勤怠カードに打刻し、月末にExcelの勤務記録表へ書き写して提出する運用になっています。サポートに入っている僕も、同じカードを使っています。

月末にまとめてやるからか、この作業に毎回20分ほどかかっていました。しかも勤怠カードの字は小さく、カードとExcelを見比べながら1日ずつ打ち込むのが、地味に面倒でした。

本当に狙っていたのは、その先の給与データ

1人あたり月20分だけなら、システムを作るほどではないかもしれません。作ろうと決めたのは、その先があったからです。

勤務記録のデータは、最終的に給与明細のデータを入力している担当者に渡ります。読み取った結果をCSV（ほかのシステムに取り込みやすい形式のデータ）で渡せれば、給与明細のシステムにそのまま取り込めて、大きく手間を減らせる。そう判断しました。

できあがった機能

Claude Codeとやり取りを重ねながら、次のような流れのシステムを作りました。

安全面にも手を入れました。カードの画像は、ログインした本人と管理者しか見られない場所に置く。AIに送る前に、ブラウザの中でカードの部分だけを切り抜く。AIを使うための鍵（APIキー）は暗号化して保存する。こうした対策をまとめた報告書も作りました。

読み取りに使うAIは、実際のカードで比べて選んだ

読み取りを担当するAIは、実際の勤怠カード10枚を使って、3つのモデルで比べました（2026年8月時点）。

いちばん軽いモデルは、1枚だけ「17:36」を「17:35」と読みました。1分のずれは、画面で見てもほとんど気づきません。でも勤怠の記録としては、はっきりした間違いです。正確さと費用のバランスから、Sonnet 5を標準にしました。

それでも、AIの読み取りを100%信じる前提にはしていません。確認画面でカードと見比べられるようにしたのは、そのためです。AIが書く「もっともらしい間違い」については、前回の記事でも書きました。

それでも、導入はされなかった

完成したシステムを説明し、使い方の資料とセキュリティの報告書も用意しました。それでも、答えは見送りでした。理由として伝えられたのは2つです。

理由1：来年の春に、全社の勤怠システムが切り替わる予定だった

来年の春に、会社全体で新しい勤怠システムへ切り替わる予定がありました。それまでの数か月だけ別の仕組みを入れても、効果が薄いという判断です。

理由2：セキュリティが大丈夫かどうか、判断できる人がいなかった

もう一つは、セキュリティの不安です。ただ、「危ない」と言われたわけではありません。問題がないかどうかを、社内で判断できる人がいない、という理由でした。

システムは僕の側で用意したサーバーで動いていたので、会社の勤怠データを社外のサーバーに置くことになります。対策をまとめた報告書を作っても、それを読んで「これなら大丈夫」と判断できる人がいなければ、話は前に進みません。判断できないものは、「使わない」が自然な結論になります。

作ったあとで分かった、もう一つの壁

見送りの理由とは別に、作ったあとで分かったこともありました。

狙っていた給与明細のシステムは、かなり古い、その会社のために一から作られたシステムでした。CSVを取り込む機能がなく、取り込めるようにするには、システム自体に手を入れる必要がありそうでした。そこまでは対応できませんでした。

つまり、仮に導入されていたとしても、いちばん効果が大きいと考えていた「給与データへの取り込み」は実現できなかったことになります。つなぎたい先のシステムが何を受け取れるのかは、作る前に確かめられることでした。

並べてみて見えた、「通る」と「止まる」の分かれ目

「止まっても元のやり方に戻れる」ものは、話を通しやすい

実は、途中の段階で試作版を見せたときには、「これは会社の中心になるシステムではないから、いいね」と言ってもらえ、開発を続けることになっていました。

勤怠カードは紙のまま残るので、システムが止まっても、これまでどおり手で書き写せば仕事は終わります。止まっても元のやり方に戻れる。この位置づけが、開発を続けられた理由でした。

会社のデータが外に出るかどうかで、判断の重さが変わる

一方で、実際に使うかどうかの段階では、会社のデータを社外のサーバーに置くことが引っかかりました。

自分のパソコンの中だけで完結する道具と、会社のデータを預かるWEBシステムでは、求められる判断の重さがまったく違います。作る側にとっては同じ「便利なツール」でも、会社にとっては「データを外に預けるかどうか」という別の話になります。

作る前に、「困っている人」と「判断する人」を見つけておく

今回は、作ってから説明して、理解してくれる人を探す順番になっていました。

これから同じように社内ツールを作る人には、困りごとが大きく、社内で声を上げてくれる人と、安全かどうかを判断できる人を、作り始める前に見つけておくことをおすすめします。どちらかがいないと、どれだけ良いものを作っても、使われるところまでたどり着きにくくなります。

AIに任せられたこと、人がやるしかなかったこと

振り返ると、AIが担ってくれた部分と、人が動くしかなかった部分は、はっきり分かれていました。

AIで作るのが速くなるほど、「作る前の確認」が大事になる

AIのおかげで、作ること自体のハードルは本当に下がりました。1人でも、ここまでのシステムを形にできます。

ただ、作るのが速くなったぶん、確認より先に作り始めてしまいやすくなります。今回つまずいたのは、どれもプログラムの問題ではありませんでした。全社の予定、判断する人、つなぎたい先のシステム。どれも、プログラムを1行も書く前に確かめられることでした。

AIで社内ツールを作る前に、確かめたい5つのこと

今回の経験から、作り始める前に確かめておきたいことを5つにまとめました。

どれも、AIに聞いても答えは出ません。社内の人に聞いたり、実際のシステムを確かめたりして、人が集めるしかない情報です。

それでも、作ってよかったと思えること

見送りについては、冒頭でも書いたとおり、半分は納得していて、半分は納得できていません。

ただ、ここで覚えた技術と経験は、次に活かしたいと思っています。

実際、作る過程で得たものは手元に残っています。紙の書類をAIで読み取る仕組み。AIの読み間違いを前提にした確認画面。Excelの様式に合わせた出力。
セキュリティ対策と、その説明のしかた。どれも、別の業務や別の会社で使える知識です。
作ったシステムも、消さずに残してあります。

まとめ｜AIが縮めてくれたのは「作る時間」だった

Claude Codeのおかげで、紙の勤怠カードを読み取るシステムを1人で作ることができました。作ることのハードルは、確実に下がっています。

ただ、社内で使ってもらえるかどうかは、別の問題でした。全社の予定、安全かどうかを判断する人、つなぎたい先のシステム。今回つまずいたのは、どれも人が確かめるしかない部分です。

AIで何かを作ろうと思ったら、作り始める前に、先ほどの5つを確かめてみてください。作る時間が短くなった今だからこそ、その確認が、作ったものを無駄にしないための近道になると思います。

トミーがいま読んでいる本PR

Claude 最強のAI自動化術

池田朋弘 著／芸術新聞社

まだ全部は読めていないのですが、読んでいてAIの使い方を3つの段階で整理できたのがよかったです。

• LEVEL 1チャットで質問して、活用する
• LEVEL 2AIに、実際に仕事をしてもらう
• LEVEL 3AIで、仕事を自動化する

「完全に自動化」と言い切るのはまだ怖いですが、業務によってはそこまで持っていけそうだと感じています。

Amazonで見る楽天ブックスで見る

※このカードのリンクはアフィリエイトリンクです。リンクから購入されると、KAKERUデザインに紹介料が入ります。

関連記事

関連記事プロンプトを長くしても、AIの仕上がりが良くならない理由｜足りないのは「判断基準」

2026.09.17