起点
ある日、勤怠管理 SaaS の契約更新通知が届きました。300 名規模で、1 人あたり月額 200 円。年間 72 万円です。
数字としては許容範囲でした。問題はコストではなく、仕様適合性でした。
第 1 章 要件定義 — 既存 SaaS の限界と内製化の判断
汎用 SaaS は、多くの企業に共通する一般的な業務を前提に設計されています。これは設計思想として正しい姿勢です。しかし、自社固有のロジックを抱えた組織では、業務が SaaS の機能と噛み合いません。
我々のケースでは、次の 2 点が SaaS の標準仕様から外れていました。
- 交通費の実費精算: 定期券区間や日別経路の判定ルールが固有で、SaaS の標準集計では扱えませんでした。
- 出社判定の運用: テレワークと出社の境界線を、社内ネットワーク経由かどうかで決めたいという要望があり、位置情報による粗い判定では運用が回りませんでした。
汎用 SaaS でこれらを実現するには、追加開発オプション、もしくは抜け道としての CSV エクスポート + 後処理運用が必要になります。前者は費用が膨らみ、後者はベンダーロックインの逆現象 (運用属人化) を招きます。
判断は単純でした。AI を外部のコーディングリソースとして起用し、GAS (Google Apps Script) で自社の要件に合うシステムを書き直すことです。
実装着手から動作確認まで、数時間で完了しました。コードは AI が書き、要件定義と仕様調整は人間が行いました。AI を利用した人間の役割を「AI ディレクター」 と呼びます。
第 2 章 物理的制約の突破プロセス (Ver.1 〜 Ver.4)
開発の途中で、位置情報の取得方式を 4 回切り替えました。それぞれが、ある制約の発見と、その制約を回避する設計判断でした。
Ver.1 HTML5 Geolocation
スマートフォンであれば GPS による精度の高い測位が可能です。しかし、勤怠打刻は PC からの操作が主であり、PC の Geolocation は Wi-Fi 三角測量や IP 経由の推定に依存するため、誤差が数 km 単位で発生しました。
「出社判定」 の用途には精度が不足するため、棄却しました。
Ver.2 IP アドレスからの推定
多くの SaaS が採用しているフォールバック手法を模倣しました。クライアント IP から地理的位置を推定する外部 API を呼び、住所文字列に変換する方式です。
これも誤差が大きいです。回線事業者のルーティングに依存するため、自宅と判定すべき場所が「東京駅周辺」 に化けるケースが頻発しました。判定としては成立しません。
Ver.3 Google Maps の Reverse Geocoding (GAS 内蔵)
GAS には Maps サービスが内蔵されており、Maps.newGeocoder().reverseGeocode(lat, lng) で逆ジオコーディングが無料で実行できます。これにより、緯度経度からの住所変換に外部 API 鍵が不要となりました。
精度の問題は残りますが、コスト面では SaaS 比較で完全に優位に立ちました。
Ver.4 マスタ照合による「出社証明」
最終的な解は、位置情報の精度を上げるのではなく、判定軸そのものを変えることでした。
社内ネットワークから打刻された場合、グローバル IP は社内ルータの固定 IP となります。この IP を社内拠点の住所マスタと照合し、一致すれば「出社」 と確定する仕組みにしました。位置精度の議論は不要になります。
この判定は IP マスタ照合という決定論的なロジックに帰着するため、誤差が構造的に発生しません。出社判定だけが目的であれば、Geolocation よりも IP 照合の方が要件に対して正確でした。
第 3 章 実装した機能
最終形は以下の機能を備えています。
- ワンタップ打刻: ブラウザから 1 ボタンで出退勤を記録します。
- 動的ロケーション記録: IP マスタで「出社」 確定、それ以外は Reverse Geocoding で住所文字列を記録します。
- 出社日数の自動集計: 月次・個人別の出社日数を、社内拠点マスタとの照合結果から算出します。
- データ所有権: 打刻データは自社の Google Spreadsheet に蓄積されます。エクスポート操作は不要で、SaaS 解約後もデータが手元に残ります。
最後の点は、ベンダーロックイン回避という観点で重要です。SaaS の場合、解約すると過去データへのアクセスが失われるか、CSV ダンプの形式でしか取り出せません。内製化により、データ構造そのものが自社の管理下に置かれます。
第 4 章 考察 — AI がもたらすレバレッジの非対称性
AI コーディング支援を語る記事の多くは、「プログラマーの生産性が N 倍になる」 という文脈で書かれます。
これは縦軸の話です。同じ職能の中で、処理スループットが上がります。タイピング速度の延長線、コードレビューの効率化、リファクタリングの加速といったところです。
一方、本ケースで起きたのは、それとは異なる方向のレバレッジです。
業務のドメイン知識を持つ人間が AI を使うと、従来は「業務側 → エンジニアへの発注 → 実装 → 検収」 という工程を経ていた業務システムが、中間工程を省いて直接構築できるようになります。
| 利用者 | AI の使い方 | 効果 |
|---|---|---|
| プログラマー | 同じ職能のスループット向上 | 縦方向の生産性 N 倍 |
| ドメイン知識保有者 | 中間工程の省略、自力で実装到達 | 「実装できなかった人」 が「実装できる人」 になる、非線形の到達 |
後者のレバレッジは、個人の市場価値の文脈で非対称です。プログラマーの生産性向上は同業者の競争を加速させる方向に働きますが、ドメイン知識保有者の AI 活用は、職能の境界線そのものを越境させます。
縦軸の加速と、職能の境界越え。両者は性質の異なるレバレッジです。AI ディレクターは後者を体現する役割と言えます。
第 5 章 サンプル成果物の活用 — 専門家への引き渡しという選択肢
勤怠管理の要望をすべて盛り込み、まずは 1 人分でも動くサンプルシステムを作ります。その後のログイン管理、変更申請の承認フロー、データベース管理といった本番運用に必要な要素は、自分で時間をかけて作り込むこともできます。しかし、この時点で SIer に発注するという選択肢も十分に成立します。
やりたいことが網羅され、一応動作するシステムが手元にあり、GAS のコードも揃っています。これは、要件定義・基本設計の一部・機能設計・詳細設計までは完了している状態と言い換えることができます。
後は全社員が利用できるシステムへの改変だけを依頼する形になれば、従来の外注費用よりコストを抑えられます。
さらに、専門の SIer に本番品質のシステムを作ってもらい、仕様書とシステム設計を成果物として納品してもらったとしましょう。その後に必要な改修は、社員数の増減によるスケール対応と、レアパターンの取り込みに限定されます。これらは仕様書とシステム設計を元に現在のシステム環境として AI に読み込ませることで、自分たちで対応できる可能性が高くなります。
ロジックの作り込みは自分たちで行い、実運用に耐える品質への引き上げを専門家に任せ、成果物は自分たちで管理する。
現状の AI は何でもできる魔法の道具ではなく、あくまで自分の思考の拡張であるので、自分の限界は AI の限界であることを認め、30 分かけても解けない問題は課題としてリストアップする。あとは課題のリストを他の人に解決してもらう。もしくはレビューしてもらって解決策を示してもらえれば先に進める。
いつものシステム開発に AI が挟まって課題を減らしていく。
これがこれからのシステム開発になっていくのではないかと思います。
第 6 章 結論
年間 72 万円のコスト削減は、本件の主要な成果ではありません。
主要な成果は、自社の業務要件の変化に対して、即座にシステムを書き換えられる体制を獲得したことです。SaaS の機能追加を待つのではなく、要件定義を書いた当日にシステムが追従します。この機動力は、コスト換算では表現しきれません。
AI コーディング時代において、コードを書く能力の市場価値は相対的に下がっていきます。代わりに上がるのは、何を作るべきかを定義し、AI に正しく指示し、出力結果を検証する能力です。
これは新しい職種というよりも、既存の業務知識を持つ人間が、AI という実装層を持つことで、自分の業務領域をシステムとして再構築できる時代の到来と読めます。
AI ディレクターとして動く能力 —— 要件を定義し、AI に作らせ、業務に組み込むこと —— は、現代の業務環境における基礎的な生存戦略の一つとして位置付けられます。
おまけ — プログラマーの知見が活かされるパターン
本論はやや AI ディレクター視点に偏りました。プログラマーの知見が活かされるパターンも整理しておきます。
AI が苦手な領域への専門化
リアルタイム制御、組込み、セキュリティ、形式検証、ミッションクリティカルな領域。
これらは AI が書いたコードを検証なしで動かすことが社会的に許容されません。専門知識の深さと堅牢性が要求される分野は、プログラマーの独壇場として残ります。
AI ディレクターが越境できる領域ではなく、プログラマーが純粋に強くなる方向です。
専門家としての知見のマネタイズ
まったく別の話ですが、ある種の契約書を AI に下書きさせ、弁護士の方に最終チェックを依頼したことがあります。弁護士の方からは2、3 のコメントで 依頼料は5,000 円で完了しました。
これを抽象化すると、 AI 時代の専門家の位置付けを示す事例と読めます。AI に下書きをさせても、法的責任の所在、ハルシネーション回避、専門家の判断の観点から、専門家のチェックは依然として価値を持ちます。
同じ構造はプログラマーにも当てはまります。AI ディレクターが作ったサンプルを、本番品質に引き上げる段階で SIer・プログラマーのチェックが必要です。これは「コードを一から書く時間」 から「コードを評価し、本番品質に引き上げる時間」 への役割変化として読めます。
専門家としての知見をマネタイズする —— 自分で全てを作るのではなく、AI で骨格が作られたものを最終品質に引き上げる役割です。これは AI 時代の専門家の新しい働き方として位置付けられます。
生産が容易になった時代において、生産者側に立ち続けるのではなく、品質を上げる側、システムを作る側に回る。
ゴールドラッシュに例えるなら、ツルハシで金を探り当てる側ではなく、ツルハシを売る側か、金を製錬する側に回るイメージです。
AI が、これまでプログラマーが時間をかけてきた領域をカバーしてくれます。空いた時間を、方法論やアルゴリズムの知識を深める方向に振り向けることが望まれます。
生産は AI に任せ、生産を担当していた人々はいままでの知見を基に批評する専門家側に回る。これがプログラマー、ひいてはあらゆる専門家のモデルケースになるのではないかと思います。