非連続な突破と堅牢さを両立する、AI時代の組織条件
生成AIを導入する企業は急速に増えている。社員へChatGPTやClaudeを配り、社内チャットボットを作り、議事録を自動化し、一部部門でAIエージェントのPoCを始める。いずれも重要な第一歩である。
しかし、AIを導入したことと、AIによって事業が変わったことは同じではない。利用者数、利用トークン数、資料作成時間の短縮は、AIが使われ始めたことを示す活動指標であって、売上、利益、顧客体験、事業スピードといった本来の成果を直接は示さない。
AI Agent Day 2026で、エヴァフォースのChief Technology Architectである星川彰男氏が扱ったのは、この次の段階である。イベント公式情報でも、同セッションは「非連続な突破」と「堅牢さの構築」を両立するAI時代の組織条件を主題としている。AI Agent Day 2026 AI活用で重要なのは、AIを導入することではない。AIによって変わり続けられる組織を作ることである。
AIが「業務プロセスの中」に入っているか
個人利用では、社員が必要な時にAIへ質問する。要約、メール、コード、アイデア出しを支援させる。これは個人の作業を速くする使い方である。
事業成果につながるAI活用では、AIが標準的な業務プロセスの一部を担う。
問い合わせ受信
↓
AIが分類・契約情報と過去履歴を参照
↓
回答案と確認事項を生成
├─ 低リスク: 承認済みルールの範囲で処理
├─ 中リスク: 担当者が根拠を確認して承認
└─ 高リスク: 専門職へエスカレーション
↓
結果を記録し、ナレッジと評価へ戻す
この状態では、AIは任意に使う補助ツールではない。業務の一つの役割を担う。そのため、次の条件が必要になる。
| 条件 | 実装すること |
|---|---|
| 業務組み込み | AIを使う場面、入力、出力、引継ぎ先を標準フローに置く |
| システム接続 | 顧客、商品、契約、履歴などの正本データへ権限付きで接続する |
| KPI接続 | 処理時間だけでなく、成約率、解約率、品質、顧客満足、売上などに結び付ける |
| 継続改善 | データ、モデル、プロンプト、ルール、評価基準を更新できるようにする |
AIの利用率ではなく、業務KPIがどう変わったかを最終的な評価に置く必要がある。
AIシステムでは「完成」より、変え続けられることが重要になる
従来の業務システムは、要件を決め、設計・開発・テストを経て本番稼働し、一定期間安定して使うことを想定していた。
AIを使うシステムは異なる。モデル性能、料金、コンテキスト長、ツール利用、音声・画像処理は短い周期で変化する。現在最適な構成が、半年後も最適とは限らない。
したがって、AI時代の競争力は最初の導入完成度だけでは決まらない。
- 新しいモデルを短期間で評価し、既存構成と比較できるか
- 業務ルールやデータを安全に更新できるか
- 問題が起きた時に原因を追跡できるか
- 変更の影響を限定し、戻せるか
- 利用者のフィードバックを評価と改善へ戻せるか
エヴァフォースが掲げる「変化への適応」は、単に新技術を早く採用することではない。技術と事業の変化を、継続的に業務・システム・組織へ反映できる能力である。Everforthの公式説明
AI変革を阻む五つの壁
AIを実業務へ組み込み、改善を続けようとすると、モデル性能とは別の問題にぶつかる。
| 壁 | 起きること | 設計上の対策 |
|---|---|---|
| 全体像の不明 | システム、データ、依存関係が分からず、変更の影響を見積もれない | 構成、データ系譜、API、変更履歴、運用手順を可視化する |
| 事業とITの分断 | 現場は早く試したく、ITは要件と統制を求め、調整が遅れる | 事業KPIを共通にし、業務・技術・統制の混成チームで進める |
| SaaSとデータの分散 | 部門ごとに定義が異なり、AIが全体を理解できない | 正本、データ定義、所有者、鮮度、アクセス権を整える |
| 権限と責任の曖昧さ | AIに何を見せ、何を実行させ、誰が承認するかが決まらない | 最小権限、承認、監査、実行上限、停止・復旧を設計する |
| 運用の遅さ | 小さな変更にも数週間かかり、AIの進化に追いつけない | 自動テスト、CI/CD、観測性、段階リリース、ロールバックを整える |
これらはAI製品を替えても解決しない。企業側のアーキテクチャと組織運営を変える課題である。
必要なのは「構想・実装・運用」を回す力
講演の論点を一般化すると、AI時代の変革には三つの能力が必要になる。
1. 非連続な構想力
「問い合わせ時間を10％短縮する」ではなく、「大部分の定型問い合わせはAIが処理し、人は難しい相談と顧客関係へ集中する」といった、仕事の前提を変える将来像を描く力である。
2. 既存業務へ実装する力
大胆な構想を、既存システム、データ、規定、顧客対応、組織の制約の中へ段階的に落とす力である。PoCが動くだけでなく、権限、監査、例外、運用コストを含めて本番化する。
3. 変更を続ける運用力
モデル、ルール、データ、利用者の振る舞い、コストが変わる前提で、評価、変更管理、監視、障害対応、教育を回す力である。
構想だけでは絵に描いた餅になる。実装だけでは小さな効率化にとどまる。運用だけでは大きな変革を起こせない。三つを掛け合わせることが必要だ。
非連続な突破には、堅牢な基盤が必要である
AI活用は「攻め」、監視・テスト・セキュリティは「守り」と分けて考えられがちである。しかし、両者は対立しない。堅牢さは、攻めるための条件である。
変更のたびに障害が起き、原因調査に何日もかかり、一部の有識者しか直せない環境では、新しいAI機能を試すこと自体が大きなリスクになる。反対に、影響範囲を確認でき、異常を早く検知し、安全に戻せるなら、組織は小さく試し、失敗から学び、次の試行へ進める。
堅牢さとは、障害が絶対に起きないことではない。安全に変更し、問題から早く回復できる能力である。
| 基盤の能力 | AI変革で得られること |
|---|---|
| 自動テストと段階リリース | AI機能やルール変更を小さく試せる |
| 監視・ログ・トレース | AIの出力、ツール呼び出し、障害の原因を追える |
| 権限と承認 | 高リスク操作を無制限に自動化しない |
| ロールバックと復旧 | 誤った変更を速く止め、戻せる |
| 変更履歴とドキュメント | 個人に依存せず、改善を引き継げる |
レガシーとモダンを分けるのは、技術の新旧ではない
古い言語やメインフレームを使っているからレガシーで、クラウドや新しいフレームワークを使っているからモダン、とは限らない。
運営としてレガシーなのは、障害を顧客からの連絡で知り、原因を特定できず、特定の人に頼り、小さな変更にも長い時間がかかる状態である。
運営としてモダンなのは、使用技術の新旧にかかわらず、次の能力を仕組みで持つ状態だ。
- 事故が起きにくい
- 事故を早く検知できる
- 原因と影響範囲を把握できる
- 安全に修正し、早く復旧できる
- その知識が個人ではなく組織に残る
モダナイゼーションの目的は、技術を新しくすることではない。安全かつ迅速に変更できる運営能力を獲得することである。
AI Powered DevOps：AIを「継続的な調査とレビュー」に使う
AIをDevOpsへ入れる基本は、従来のDevOpsやSREの考え方を捨てることではない。監視、異常検知、原因調査、修正、テスト、安全なリリースというループを、AIで広く・速く回すことである。
監視データ・ログ・構成情報・コード・変更履歴
↓
AIが異常候補・影響範囲・修正案を提示
↓
人が根拠、リスク、修正内容を確認
↓
自動テスト・段階リリース・監視
↓
結果を評価セット、運用ルール、ドキュメントへ戻す
AIは、個人の経験に頼っていた定性的なレビューも支援できる。たとえば「責任分界が明確か」「特定サービスへの依存が過度ではないか」「一つの障害が全体へ波及しないか」といったアーキテクチャ原則を自然言語で定義し、コード・構成・設計資料を継続的に照合させる。
ただし、AIが判定したから合格とするのではない。AIの指摘をレビューの入口にし、根拠、影響、例外を人が確認する。品質を個人の記憶から、テスト・ルール・監視・レビューの仕組みへ移すことが目的である。
組織条件1：タレントへ投資する
モデル、クラウド、データベース、開発ツールは外部から利用できる。しかし、次の能力は簡単に借りられない。
- 不確実な状況で事業の方向を決める力
- 現在の延長ではない顧客体験を構想する力
- 現場の制約を理解して実装へ落とす力
- 関係者を巻き込み、困難を突破する力
- 特定の事業や運用で蓄積した知識
AI時代の人材投資は、研修を受けさせることだけではない。実際の課題、意思決定の機会、失敗と改善の場、必要な情報と権限を与え、能力を発揮できるチームを作ることである。
組織条件2：アライメントで、速度と統制を両立する
アライメントとは、全員を同意させることではない。誰が決めるか、何を共通原則とするか、どの範囲を専門家へ任せるかを明確にすることである。
| アライメントの設計 | 期待する効果 |
|---|---|
| 意思決定者を最小化する | 関係者全員の承認待ちを減らす |
| 専門領域に裁量を渡す | セキュリティ、AI、データ、アーキテクチャの判断を速くする |
| 長期計画を固定し過ぎない | モデルや市場の変化に合わせて優先順位を更新できる |
| 制約と背景を開く | タレントが誤った方向へ進まず、自律的に判断できる |
アライメントの目的は細かく統制することではない。共通の方向と制約の中で、高速に試行できるようにすることである。
組織条件3：オープンオーナーシップで能力を広げる
優秀な人材へ責任と知識が集中すると、その人がいなければプロジェクトが止まる。そこで、中心となるタレントが方向性やアーキテクチャを示しつつ、設計、意思決定の背景、コード、設定、運用ルールを開き、複数の人が参加・改善できる状態を作る。
これはオープンオーナーシップである。タレントは一人で全てを行う英雄ではない。組織の能力を引き上げる核である。
外部パートナーを使う場合も同じだ。依頼されたものを作らせるだけでは、顧客側へ知識が残らない。課題の定義、実験、設計、運用を共同で行い、社内メンバーが将来も改善できる状態を目指す。
Leap and Loop：突破と改善を交互に回す
既存システムが不安定で、データが整理されず、運用が属人化している企業は、いきなり大きなAI変革へ飛べない。最初に必要なのは、障害削減、可視化、ドキュメント整備、テスト、運用改善である。
一方、改善だけを続けても、非連続な変化は起きにくい。基盤が整い、機会が見えた段階では、従来の延長ではない業務、システム、顧客体験へ跳躍する必要がある。
Loop: 安定化・可視化・改善・学習
↓
Leap: 新しい業務モデル・顧客体験・アーキテクチャへ突破
↓
Loop: 運用・品質向上・知識蓄積・次の機会の発見
常に大改革を続けるのではない。堅牢さを作り、探索し、適切な時に跳躍し、また改善する。この循環が、AIで変わり続ける企業の現実的な進め方になる。
IT技術者が実行すべきこと
- AIの活動量ではなく、事業KPIを定義する。 利用率、トークン、PoC数を最終成果にしない。
- 業務の流れと待ち行列を可視化する。 AIで速くなった工程の次に何が詰まるかを見る。
- 正本データ、権限、監査を先に整える。 AIを業務へ入れるための前提を省略しない。
- 変更に強い基盤を作る。 テスト、CI/CD、観測性、ロールバック、障害対応を整える。
- 品質基準を言語化する。 熟練者の暗黙知を、ルール、テスト、評価ケース、レビュー項目へ移す。
- AIを調査・レビュー・運用支援へ使う。 ただし高リスクの判断と承認は人が担う。
- 構想・実装・運用を分断しない。 事業、技術、運用、セキュリティが同じKPIで改善を回す。
- 知識と責任を開く。 個人や外部パートナーに依存せず、組織で改善できる状態を作る。
まとめ：目指すのは、AIを導入した会社ではない
AI時代に強い企業は、最も多くAIツールを導入した企業でも、最も新しいモデルを使っている企業でもない。
技術や環境が変わった時、自らの業務、システム、組織を安全かつ素早く変えられる企業である。
そのためには、非連続な未来を描く構想力、既存業務へ落とす実装力、変え続ける運用力が必要になる。そしてそれを支える、テスト、監視、データ、権限、ログ、復旧、学習の基盤が必要になる。
非連続な突破と堅牢さは対立しない。堅牢さがあるからこそ、組織は安心して大きく変われる。目指すべきはAIを導入した会社ではない。AIを使って、変化と改善を繰り返せる会社である。
作成日: 2026年7月24日