コードを書かなくても、社内システムは運用まで進められるのか
「自社の仕事に合うシステムが欲しい。しかし、既製品に業務を合わせるのは難しい」
「AIがコードを書けると聞くが、本当に社内で使えるところまで作れるのか」
同じように感じている中小企業の経営者や管理職は少なくないでしょう。
サイバーフォレスト株式会社では、10年ほど本格的なプログラミングから離れていた社長が、OpenAIのコーディングエージェント「Codex」と対話しながら、顔認証を使う社内向け勤怠管理システムを構築しました。
コードを手入力せず、着手から約1週間で社内運用を開始しています。
ただし、AIへ「勤怠管理システムを作って」と1回頼んだだけではありません。業務ルールを決め、結果を確認し、実際の端末で試し、問題があれば修正する。この往復を重ねました。
この記事の結論
AIが実装を担当できても、目的、権限、正しい業務ルール、公開の判断は人が決める必要があります。この役割分担ができれば、長くコードを書いていない経営者や管理職でも、AIと協力して社内システムを形にできます。
約1週間で運用を始めた勤怠管理システム
今回構築したのは、東京事務所の約10名が利用する社内向けシステムです。
最初の運用に必要な機能を優先し、次のような仕組みを段階的に実装しました。
- タブレットやPCのブラウザを使った顔認証
- 出勤、退勤の打刻
- 社員本人からの打刻修正申請
- 管理者による承認、却下
- 当日と過去の打刻確認
- 社員別の月次勤務表
- CSV、Excel、PDFによる出力
- 社員、所属、部署、シフト、休日などのマスター管理
- 操作履歴を残す監査ログ
- 申請や結果のメール通知
- VPS上でのHTTPS運用
打刻時刻の原本を社員が直接変更するのではなく、修正は申請と承認の履歴として残す設計です。
画面が動くだけのデモではなく、毎日使うこと、操作を間違えること、後から確認することまで考えたシステムにしました。
Codexに任せたこと、人が決めたこと
Codexは、OpenAIが提供するソフトウェア開発用のコーディングエージェントです。コードの作成、レビュー、デバッグなどを支援します。
今回の開発でも、実装や既存コードの調査、自動検査、関連文書の更新などでCodexを活用しました。
一方、次の判断は人が担当しました。
- 誰が何を操作できるか
- 打刻原本を変更してよいか
- 修正履歴をどこまで残すか
- 退職者の過去データをどう扱うか
- 顔認証に失敗したとき何を表示するか
- どの状態なら本番で使い始めてよいか
AIは実装を速められますが、自社の就業ルールや現場の使いやすさまで自動的に決めてくれるわけではありません。
約1週間で運用へ進めた5つのポイント
1．目的を1文に絞る
最初に「約10名の出退勤を顔認証で記録し、管理者がWebで確認できる社内システム」と目的を固定しました。
将来欲しい機能をすべて並べる前に、誰のどの問題を解決するのかを明確にします。
2．利用者と権限を先に決める
従業員、承認者、管理者では、見られる情報と許される操作が異なります。画面の見た目より先に「誰が何をできるか」を決めました。
3．最初から完成形を目指さない
まず顔認証と打刻などの核となる機能を動かし、運用に必要な機能を順番に追加しました。
4．テスト環境と本番環境を分ける
新しい機能はテスト環境で確認してから反映します。PCだけでなく、実際に使うiPadやブラウザでの表示と操作も確認しました。
5．運用開始後の違和感を改善へ戻す
公開は完成ではありません。検索の初期期間、ボタンの位置、帳票の収まり方など、実際に使って初めて分かる課題を継続して直しています。
「約1週間で完成」ではなく「約1週間で運用開始」
今回の約1週間という期間は、すべての機能を完成させた期間ではありません。
まず社員が使える状態まで進め、その後も顔登録、メール通知、PDF出力、画面表示などを改善しています。
この違いは重要です。AIを使った開発では、短期間で大量の機能を作ることより、最初の利用範囲を決め、安全に使い始め、現場の結果を次の改善へつなげることが大切です。
失敗した変更を元へ戻したこともある
ある改善では、勤務時間の計算を便利にするため、休憩時間内の打刻を自動調整する処理を追加しました。
ところが、実際の運用ルールと照らすと採用しない方がよいと判断し、翌日に元の計算へ戻しました。
AIが正しくコードを書けたとしても、その仕様が会社のルールとして正しいとは限りません。
この経験から、変更前に影響する画面、帳票、集計、過去データを確認し、問題があれば戻せる単位で変更することを徹底しています。
詳しい進め方と依頼テンプレートをnoteで公開
この開発実録を、サイバーフォレスト株式会社のnote記事にまとめました。
note記事では、ここまで紹介した経緯に加えて、次の実務資料を掲載しています。
- AIへ最初に伝える7項目
- そのまま使える初回依頼テンプレート
- 「現象・条件・期待結果」で書く修正依頼テンプレート
- 本番公開前の確認チェックリスト
- AIに任せやすいことと、人が判断すべきこと
note記事：10年コードを書かなかった社長が、Codexと約1週間で勤怠管理システムの運用を始めるまで
Codexを使った社内システム開発でよくある質問
プログラミング経験がなくても同じように作れますか？
コードを手入力しなくても開発を進められる可能性はあります。ただし、業務ルールを説明し、結果を確認し、間違いを判断する役割は必要です。最初は、失敗しても戻せる小規模な社内業務から始めるのが安全です。
1回の指示でシステムが完成したのですか？
いいえ。目的と権限を決め、実装結果を確認し、修正を依頼する作業を繰り返しました。約1週間は運用開始までの期間であり、その後も改善を続けています。
顔認証を使えば本人確認は完全ですか？
完全とは言えません。認識のしきい値、撮影環境、誤認識への対応、顔情報の取扱い、代替手段などを検討する必要があります。重要な判断を顔認証だけに依存させず、運用と監査を組み合わせます。
AIに本番公開まで任せても安全ですか？
本番反映の手順作成や検査にAIを活用できますが、公開の承認まで自動化することは勧めません。バックアップ、切り戻し、秘密情報、既存データへの影響を人が確認し、最終判断を行います。
まとめ：コードを書く力だけでなく、仕様を決める力が重要になる
10年ほど本格的なプログラミングから離れていても、Codexと協力し、約1週間で勤怠管理システムの社内運用を始められました。
短期間で運用へ進めた理由は、完璧な指示を1回で作れたからではありません。
- 目的を1文に絞る
- 利用者と権限を先に決める
- 最初の運用範囲を小さくする
- テスト環境と本番環境を分ける
- 現場の声を改善へ戻す
この往復を続けたことが、実際に使えるシステムにつながりました。
具体的な依頼文と公開前チェックリストを確認したい方は、note記事をご覧ください。
参考情報
確認日：2026年9月27日
