
著者 / Author
柴 悠介
株式会社リクステップ代表。AI/DX支援、業務システム開発、ステップシリーズの開発を担当。中小企業の業務フロー、AI活用、セキュリティ、プロダクト開発を、現場で運用できる仕組みとして設計している。
AIエージェントや生成AIを開発に使うと、最初に感じるのはスピードです。画面のたたき台、APIの雛形、テスト、文章、設定ファイル。 これまで半日かかっていたものが、数分で出てくることがあります。
ただし、ここで勘違いしてはいけません。速く作れることと、会社に価値が残ることは別です。 むしろAIで作る速度が上がるほど、間違ったもの、使われないもの、将来の運用を重くするものも速く増えます。
リクステップがAI/DXやステップシリーズの開発で重視しているのは、AIで作業量を減らすことだけではありません。 業務の流れ、判断基準、権限、ログ、改善サイクルまで含めて、会社の中に価値が残る仕組みに変えることです。
1「ゼロから作れる」は、もう希少性ではなくなる
AIで作り始めるコストが大きく下がった
生成AIが開発現場に入ってから、もっとも大きく変わったのは「作り始めるコスト」です。以前は、空のファイルからコードを書き、画面を作り、APIをつなぎ、テストを書くまでに相応の時間がかかりました。
今は、方向性と制約を与えれば、AIがかなりの量を一気に生成します。これはエンジニアの仕事が消えるという単純な話ではありません。「言われたものをゼロから作る」だけの価値が下がり、「何を作るべきか」を決める価値が上がるという話です。
中小企業のDXでは、この差が特に大きく出ます。大企業のように専門部署が分かれていない分、現場の事情、経営判断、顧客対応、既存システムの制約が一つの業務に重なります。 その状態で「AIで作れるから作る」と進めると、画面は増えても業務は軽くなりません。
2加速したのは実装。詰まり始めるのは、その前後
AIは実装を速くするが、事業全体を自動で速くするわけではない
AIは実装を速くします。しかし、要件定義、承認、レビュー、リリース後の運用まで同じ速度で進むわけではありません。実装だけが速くなると、今まで見えにくかった前後の詰まりがはっきり見えます。
| 領域 | AI時代に詰まる理由 | 整えるべきこと |
|---|---|---|
| 要件定義 | 誰の、どの業務を、どこまで短くするのかが決まっていない | 業務フロー、例外、判断基準、完了条件を先に言語化する |
| 開発環境 | CIが遅い、テストが不安定、ローカル再現に時間がかかる | AIも人間も同じ手順で検証できる状態にする |
| レビュー | 人間が全差分を読む前提だと生成量の増加に追いつかない | Lint、型、テスト、権限、監査ログで機械的に落とす |
| 運用 | 問い合わせ、設定、説明が増え、現場が疲弊する | 使われる導線、サポート導線、ログ設計まで含めて作る |
つまり、AIで加速するほど、人間が見るべき場所はコードそのものから、コードの前後へ移ります。 どの業務を対象にするのか。誰が使うのか。使われなかった場合、何が無駄になるのか。リリース後、問い合わせや設定の負担は増えないのか。 こうした問いに答えないまま作ると、AIで速く作った分だけ、あとで戻すコストも速く積み上がります。
3人間に残るのは、作業ではなく意思決定
AIが速いほど、決める力の差が成果の差になる
AI時代に人間へ残る役割は、根性で作業量をこなすことではありません。むしろ、作業量そのものはどんどんAIへ移ります。 その代わりに重要になるのは、何を作るか、何を作らないか、どの順番で進めるか、どこまでを自動化するかを決めることです。
特に重要なのは「作らない判断」です。AIで作れるようになると、機能追加の心理的ハードルが下がります。 しかし、使われない機能は、作った瞬間から説明、保守、テスト、問い合わせ、権限管理の対象になります。
| 判断 | AI時代に起きやすい失敗 | 人間が決めるべきこと |
|---|---|---|
| 作る | 要望があるからすぐ作る | 誰の業務時間をどれだけ減らすか |
| 作らない | 作れるのに作らない理由を説明できない | 将来の運用負荷と効果の差 |
| 後回し | 優先順位が曖昧なまま積み上がる | 今やるべき業務ボトルネックか |
| 撤退する | 一度作ったものを消せない | 使われない機能を落とす基準 |
AIが強い会社ほど、判断の型を持っている
AIを使いこなす会社は、プロンプトが上手いだけではありません。判断の型を持っています。 何を見れば採用するのか、どの条件なら止めるのか、どのリスクなら人間承認に戻すのかが決まっています。 この型があるから、AIに任せる範囲を広げても品質が崩れにくくなります。
4AIを待たせない環境は、そのまま経営効率になる
待ち時間、再現性、文脈不足がAI活用の費用になる
AIエージェントは、待ち時間に弱い存在です。CIが遅い、テストが不安定、環境構築が属人化している、仕様が散らばっている、権限が毎回止まる。こうした状態では、人間もAIも同じ場所で止まります。
AIを待たせないために整えるもの
- □誰でも同じ手順で立ち上がる開発環境
- □AIが読める仕様・業務ルール・判断基準
- □短時間で終わるCIと安定したテスト
- □本番・顧客情報・外部送信に関する権限ルール
- □レビュー前に機械的に落とせる品質チェック
- □失敗時に戻れるログと再現手順
これは開発会社だけの話ではありません。営業資料、問い合わせ対応、申請業務、採用、経理、顧客管理でも同じです。AIを使う前に、情報の置き場所、判断のルール、承認の流れ、ログの残し方を整えることが必要です。
AI活用のコストは、API料金やツール利用料だけではありません。AIへ毎回同じ説明をする時間、担当者が出力を読み解く時間、間違いを戻す時間、権限確認で止まる時間もコストです。 環境を整えるとは、この見えにくいコストを減らすことです。
5ガードレールは、自然言語ではなく仕組みで強制する
お願いではなく、通らなければ進めないルールにする
「個人情報を見ないでください」「本番を触らないでください」「勝手に送信しないでください」と書くだけでは足りません。自然言語は解釈の余地があり、忙しい現場では読み飛ばされます。
| 項目 | 自然言語だけの問題 | 仕組み化の方向 |
|---|---|---|
| 権限管理 | 誰が何を触れるかが曖昧になる | データ・操作・承認レベルを分ける |
| CI / Lint / 型 | 品質ルールがお願いになる | 通らなければマージできない状態にする |
| 監査ログ | 誰が何をしたか追えない | AI・人間・外部ツールの操作履歴を残す |
| 業務ルール | 例外対応が担当者の記憶に閉じる | 申請、承認、通知、差し戻しをデータ化する |
セキュリティに強い開発とは、開発者の注意力に依存しない状態を作ることです。見てはいけないデータにそもそも触れない。 通してはいけない変更はCIで止まる。送ってはいけない情報は外部送信前に検知される。誰が何を実行したかはログで追える。
AIエージェントを入れるなら、この考え方はさらに重要です。AIは速く動くため、誤った権限や曖昧なルールがあると、失敗も速く広がります。 だからこそ、AI/DXは便利さだけでなく、最初からセキュリティと監査を含めて設計する必要があります。
6速く作るほど、プロダクト設計が重要になる
機能追加の誘惑に負けると、未来の運用が重くなる
AIで開発速度が上がると、機能追加の誘惑が強くなります。要望を聞いたら作れる。画面もすぐ増やせる。設定も増やせる。 しかし、機能は作った瞬間に価値になるわけではありません。使われ、運用に乗り、改善に必要なデータが残って初めて価値になります。
使われない機能は、ユーザーにとっては迷いになります。開発者にとっては保守対象になります。AIにとっては無駄な文脈になります。 中小企業DXでは、限られた人数で長く運用する必要があるため、機能の増やしすぎはそのまま将来の負担になります。
| 増やしたもの | 一見よいこと | 後から効く負担 |
|---|---|---|
| 設定項目 | 柔軟に見える | 誰も最適値を判断できなくなる |
| 画面 | 業務ごとに専用化できる | 導線が分かれ、教育と問い合わせが増える |
| 通知 | 見落としを防げる | 通知疲れで重要なものまで読まれなくなる |
| 例外処理 | 個別事情に対応できる | 標準フローが壊れ、改善データが集まらない |
7ボトルネックは、技術ではなく組織構造に移る
部分的な自動化だけでは、会社全体は速くならない
AIが実装を速くすると、次に遅く見えるのは組織です。担当者が決められない。上長確認で止まる。部門ごとに情報が分断されている。現場の要望はあるが、誰も全体像を持っていない。
こうなると、AIの性能を上げても大きな成果は出ません。部分的な自動化は増えますが、会社全体の処理時間は変わらない。局所最適によって、ボトルネックが別の部署へ移動するだけです。
組織が遅いままAIだけ速くしても、現場は楽になりません。AIが作ったものを誰が確認するのか。現場が使わない場合、誰が原因を見るのか。 業務ルールを変える権限は誰にあるのか。こうした意思決定の流れが曖昧だと、AIは「速く作る人」を増やすだけになります。
本当に必要なのは、AIを入れることではなく、AIが動ける会社の形に変えることです。 人間が判断すべきところ、人間承認が必要なところ、AIに任せてよいところ、ログとして残すところを分ける。 その設計ができて初めて、AIの速度が会社全体の速度になります。
8ステップシリーズで考えていること
単発機能ではなく、業務の通り道を作る
リクステップが進めているステップシリーズは、単に機能を増やすための開発ではありません。 申請、確認、承認、差し戻し、通知、記録、分析といった業務の流れを、企業の中に残る仕組みに変えるための開発です。
業務システムで価値が残るのは、画面の数ではありません。誰が、いつ、何を判断し、なぜ差し戻され、次にどう改善されたのかが残ることです。 そのログがあるから、次の担当者は迷いにくくなり、AIも業務の文脈を読み取りやすくなります。
| ステップシリーズで残したいもの | AI/DX上の意味 |
|---|---|
| 申請の入力内容 | AIが必要情報の不足を検知できる |
| 承認・差し戻し理由 | 判断基準を組織知として蓄積できる |
| 通知と対応履歴 | 誰がどこで止まっているかを見える化できる |
| 完了後のデータ | 改善、分析、次回自動化の材料になる |
これは、AI時代の企業にとって重要な考え方です。AIモデルそのものは入れ替わります。 しかし、自社の業務ログ、判断基準、例外対応、改善履歴は会社に残せます。 その蓄積こそが、AIを使った競争力になります。
9中小企業が始める順番
AIツール導入より先に、業務の型を整える
中小企業がAI/DXを始めるとき、最初から大きなAIエージェントを作る必要はありません。 むしろ、いきなり自動化しようとすると、業務の曖昧さがそのままAIの失敗になります。 最初にやるべきなのは、重要な業務を一つ選び、流れと判断を整理することです。
| 順番 | やること | 目的 |
|---|---|---|
| 01 | よく詰まる業務を一つ選ぶ | 効果が見える範囲に絞る |
| 02 | 開始条件と完了条件を決める | AIと人間が同じゴールを見る |
| 03 | 例外と差し戻し理由を集める | 暗黙知を判断基準に変える |
| 04 | 権限とログを設計する | 安全に任せられる範囲を決める |
| 05 | 小さくAIに任せて検証する | 失敗を業務ルールへ戻す |
この順番で進めると、AI活用は単発の効率化ではなく、会社の学習になります。 うまくいったことだけでなく、間違った回答、足りなかった情報、承認で止まった理由まで残す。 それを次の改善に戻すことで、AIと業務が一緒に育っていきます。
10リクステップの結論:AI/DXは、業務OSの再設計
ツール導入ではなく、AIが実行できる会社の形に変える
AI時代のDXは、ChatGPTを入れることでも、既存業務をそのまま自動化することでもありません。会社の業務を、AIが実行でき、人間が判断でき、ログが資産として残る形に再設計することです。
リクステップでは、ホームページ制作、AI/DX支援、業務システム開発、ステップシリーズの開発を通じて、企業の「クリックを減らす」「判断を残す」「業務ログを資産にする」仕組みを作っています。
AI/DXで整えるべきこと
- □業務フローと完了条件
- □権限管理と情報セキュリティ
- □AIが読めるナレッジベース
- □CI・テスト・監査ログ
- □導入後の運用と改善サイクル
- □作らない判断を含むプロダクト設計
AIで速く作ることは、これからの前提になります。だからこそ、速度そのものを目的にしてはいけません。 速く作ったものが、現場の迷いを減らし、判断を残し、業務ログとして蓄積され、次の改善に使われるか。 そこまで見て初めて、AI/DXは会社の力になります。
リクステップは、AIを「便利な作業代行」としてだけ見ていません。企業の業務を、AIが実行でき、人間が判断でき、セキュリティと監査で守られ、ログが資産として残る形に変えるための技術だと捉えています。 ゼロから作るだけの時代が終わるなら、次に必要なのは、価値が残る会社の仕組みを設計する力です。
関連記事
よくある質問(FAQ)
AI時代にエンジニアやDX担当者の仕事はなくなりますか?
単に指示されたものを作るだけの仕事は減ります。一方で、何を作るべきかを決める、業務全体を整理する、AIが安全に速く動ける環境を作る、成果物を事業価値につなげる仕事の重要性は上がります。
中小企業がAI/DXで最初に整えるべきことは何ですか?
AIツールの導入より先に、業務フロー、判断基準、データの置き場所、承認ルール、完了条件を整理することです。AIが迷わず実行できる状態を作るほど、導入効果は大きくなります。
なぜガードレールを自然言語だけに頼ってはいけないのですか?
自然言語の注意書きは解釈の余地があり、運用が崩れやすいためです。権限管理、CI、Lint、監査ログ、承認フローなど、仕組みとして強制されるルールに落とし込む必要があります。




