「AIに作らせる」だけでは、現場の責任は消えない
生成AIの進化によって、IT技術者の仕事はすでに変わり始めています。
仕様書のたたき台を作る。コードの一部を書かせる。エラーの原因を調べる。テストケースを考えさせる。ドキュメントを要約する。
こうした使い方は、もう珍しいものではありません。
ただし、これから起きる変化は、単なる「便利な補助ツール」の延長ではありません。焦点は、質問に答えるAIから、目的に向かって作業を進めるAIエージェントへ移っていきます。
AIエージェントは、与えられた目的をもとに、作業を分解し、情報を参照し、ツールを使い、途中結果を確認しながら処理を進めます。
たとえば、次のような依頼を考えてみます。
この既存システムの仕様書とコードを確認し、
影響範囲を洗い出し、
修正案を作り、
必要なテスト観点までまとめてください。
従来のAI利用なら、技術者が仕様書を貼り付け、コードを貼り付け、質問を分けて投げ、出力をつなぎ合わせて判断していました。
AIエージェントの世界では、AIがリポジトリを読み、関連ファイルを探し、変更箇所を推定し、テストコードを書き、Pull Requestの説明文まで作るようになります。CIの結果を見て修正案を出す、チケットを更新する、関連ドキュメントを直す、といった流れも現実的になります。
これは作業効率化の話だけではありません。
IT技術者の仕事の中心が、「自分で全部作る」ことから、「AIに任せる仕事を設計し、その結果を検証し、責任を持って判断する」ことへ移っていくということです。
コードを書く力より先に、コードを読んで判断する力が問われる
AIがコードを書けるようになると、「プログラマーは不要になるのか」という話になりがちです。
しかし、業務システムの現場ではそこまで単純ではありません。
確かに、定型的なコード、画面のひな形、API呼び出し、簡単なバッチ処理、テストのたたき台は、AIによってかなり速く作れるようになります。自然言語で作りたいものを伝え、AIと対話しながらアプリケーションを形にする開発スタイルも広がるでしょう。
これは大きな可能性です。
非エンジニアでもプロトタイプを作れる。若手技術者でも短時間で動くものを作れる。経験者であれば、面倒な初期実装をAIに任せて、設計や品質確認に時間を使える。
一方で、ここには落とし穴があります。
動いたからよい。
バグが出たらAIに直させればよい。
コードの中身は読めなくても、目的の動作をしていればよい。
小さな個人用ツールなら、それでも済むかもしれません。しかし、企業のシステムでは、データ、権限、認証、ログ、例外処理、性能、可用性、保守性、監査性が関わります。
AIが生成したコードが一見正しく動いていても、次のような問題を含んでいる可能性があります。
- 入力チェックが不十分である
- 例外処理が雑である
- 認可の確認が抜けている
- SQLやAPIの使い方にセキュリティ上の問題がある
- 同じ処理が重複していて保守しにくい
- 本番環境では性能問題を起こす
- ログに個人情報や機密情報を出力している
- 仕様変更時に影響範囲が追えない
AIがコードを書ける時代ほど、技術者にはコードを読む力が必要になります。
これからのIT技術者に求められるのは、AIより速くコードを書くことではありません。AIが書いたコードを読み、構造を理解し、リスクを見抜き、必要な修正を判断できることです。
本当に必要なのは、プロンプト術より「任せ方の設計」
AIエージェント時代の技術者に必要なのは、単なるプロンプトの工夫ではありません。
もちろん、AIに適切な指示を出す力は重要です。しかし、それだけでは不十分です。
本当に重要なのは、AIにどの作業を任せるのか、どの情報を渡すのか、どの操作を許可するのか、どこで人間の確認を入れるのかを設計する力です。
たとえば、AIエージェントに開発支援をさせる場合、次のような判断が必要になります。
| 設計項目 | 考えるべきこと |
|---|---|
| 読み取り範囲 | リポジトリ全体を読ませるのか、特定ディレクトリだけにするのか |
| データアクセス | 本番データ、顧客情報、秘密情報に触れさせてよいのか |
| 書き込み権限 | ファイル変更、ブランチ作成、PR作成まで許可するのか |
| 実行権限 | テスト、ビルド、CI/CD、クラウド操作をどこまで許可するのか |
| 承認ポイント | どの操作から人間承認を必須にするのか |
| 失敗時対応 | 誤変更、誤送信、誤削除が起きたときに戻せるのか |
この設計を誤ると、AIは便利な助手ではなく、危険な自動操作主体になります。
AIエージェントは、チャット画面の中だけで完結する存在ではありません。ファイル、Git、チケット管理、メール、カレンダー、クラウド環境、監視ツール、CI/CD、データベースなどと接続されていきます。
AIに権限を与えるということは、実際の業務環境に操作権限を与えるということです。
だからこそ、AIエージェントを導入するとき、技術者は「便利かどうか」だけでなく、「安全に運用できるか」を設計しなければなりません。
最初に決めるべき4点は、権限・ログ・承認・ロールバック
AIを業務に組み込むとき、IT技術者が最初に考えるべきことは、派手な活用事例ではありません。
まずは、次の4点です。
1. 権限
AIに必要以上の権限を与えてはいけません。
人間のユーザー管理と同じように、AIにも最小権限の原則を適用する必要があります。
- 読み取りだけでよいのか
- 書き込みが必要なのか
- 削除権限は必要なのか
- 本番環境にアクセスできる必要があるのか
- 個人情報や機密情報を扱わせてよいのか
AIは、大量の情報を高速に処理し、複数の操作を連続して実行できます。だからこそ、人間以上に慎重な権限設計が必要です。
2. ログ
AIが何を読んだのか。何を判断したのか。どのファイルを変更したのか。どのコマンドを実行したのか。どの外部サービスにアクセスしたのか。
これらを追跡できなければ、問題が起きたときに原因を調べることができません。
AIの最終出力だけを見ても、途中で何が起きたのかが分からなければ、企業システムには使いにくいのです。
3. 承認
AIが提案するところまでは自動化してよい。
しかし、実際の変更、外部送信、本番反映、権限変更、顧客影響のある処理は人間が確認する。
この線引きが重要です。
特に、AIが作成したメールを自動送信する、AIが本番データを更新する、AIがクラウドリソースを作成・削除する、AIがセキュリティ設定を変更する、といった処理は慎重に扱う必要があります。
4. ロールバック
AIが誤った変更をした場合に、元に戻せるか。
どの時点まで戻せるか。変更前後の差分を確認できるか。影響範囲を追跡できるか。
AIエージェントを使うなら、「間違えないこと」を前提にしてはいけません。間違える可能性を前提に、止める、戻す、調べる仕組みを用意する必要があります。
社内情報が荒れていると、AIは賢く働けない
AIエージェントを導入すれば、すぐに業務が効率化されると思われがちです。
しかし、その前に大きな課題があります。
AIが参照する情報の品質です。
- 社内文書が古い
- 最新版がどれか分からない
- 同じ手順書が複数ある
- ルールと実運用が違う
- 設計書と実装がずれている
- ナレッジが個人の頭の中にある
- 過去の障害対応記録が検索しにくい
- チケットの書き方が担当者ごとに違う
この状態でAIエージェントを導入しても、AIは正しく働けません。
AIは、与えられた情報をもとに処理を進めます。参照先が混乱していれば、AIの判断も混乱します。古い資料を正しいものとして扱えば、古い手順を提案します。誤った設計書を参照すれば、誤った修正案を出します。
つまり、AI活用の前提として、情報アーキテクチャの整備が必要になります。
AIエージェント時代における技術的負債は、コードだけではありません。
読めない設計書。検索できない議事録。更新されない手順書。属人化した運用。根拠が残っていない判断。構造化されていないチケット。
これらも、AI活用を妨げる負債になります。
開発プロセスは「AI前提」に作り直す
AIエージェントが開発現場に入ると、開発プロセスそのものも変わります。
要件定義では、AIが議事録から論点を整理し、未決事項や矛盾を洗い出す。
設計では、AIが既存設計との整合性を確認し、影響範囲を提示する。
実装では、AIがコードのたたき台を作り、リファクタリング案を出す。
テストでは、AIが境界値、異常系、回帰テスト観点を生成する。
レビューでは、AIが差分を読み、潜在的な問題を指摘する。
運用では、AIがアラートを要約し、過去事例と照合し、初動対応案を提示する。
この流れ自体は有効です。
ただし、AIを既存プロセスに雑に追加するだけでは、品質は上がりません。むしろ、責任の所在が曖昧になる危険があります。
- AIが書いたコードを誰がレビューするのか
- AIが作ったテスト観点を誰が承認するのか
- AIが見落とした問題の責任はどこにあるのか
- AIの提案を採用した理由は記録されているのか
- AIが参照した情報は妥当だったのか
企業システムにおいて重要なのは、速さだけではありません。
なぜその設計にしたのか。なぜその実装でよいと判断したのか。どのリスクを受け入れたのか。どのテストで確認したのか。障害時にどこまで追跡できるのか。
こうした説明責任を果たせる開発プロセスにする必要があります。
役割別に準備することは違う
AIエージェント時代は、特定の一部の技術者だけに関係する話ではありません。
ITに関わるすべての職種が、自分の専門領域にAIが入ってきたとき、何が変わるのかを考える必要があります。
| 役割 | 準備すべきこと |
|---|---|
| アプリケーション開発者 | AI生成コードのレビュー観点、テスト方針、責任ある採用基準を持つ |
| インフラエンジニア | AIがクラウドリソースや構成情報を扱うときの権限と監査を設計する |
| セキュリティ担当者 | AI経由の情報漏えい、プロンプトインジェクション、認可の抜け道を確認する |
| 運用担当者 | AIが障害対応に関与する場合の確認手順とエスカレーションを整える |
| アーキテクト | AIを前提としたシステム構成、データ連携、ガバナンスを設計する |
| マネージャー | AI利用時の責任分界点、レビュー体制、人材育成を整える |
これから求められるのは、「AIを使える技術者」ではなく、「AIを安全に業務へ組み込める技術者」です。
若手技術者は、AIに作らせた後に説明できるかを問う
AIがコードを書ける時代に、若手技術者は何を学ぶべきでしょうか。
AIを使えば、初学者でも動くアプリを作れるようになります。これは学習の入口として大きな意味があります。自分のアイデアがすぐ形になることで、学ぶ意欲が高まるからです。
しかし、コードを読まないまま、AIに作らせるだけの学習になってしまうと危険です。
- なぜこの処理が必要なのか
- この関数は何を受け取り、何を返すのか
- このエラーはどこで起きているのか
- この設計だと、あとで何が困るのか
- 入力値が想定外だったらどうなるのか
- データが増えたら性能は大丈夫なのか
- 認証や権限はどこで確認しているのか
こうした問いを持てないまま、AIに修正を繰り返させるだけでは、技術力は積み上がりません。
これからの学習では、「AIに作らせる」ことと「自分で理解する」ことを分けて考える必要があります。
AIにたたき台を作らせるのはよい。AIにエラーの原因を説明させるのもよい。AIに別解を出させるのもよい。
しかし最後には、自分で読めること、自分で説明できること、自分で危険箇所を指摘できることが必要です。
企業の新人育成でも、教育機関でのプログラミング教育でも、提出物が動いているかどうかだけを見るのでは不十分です。本人が構造を説明できるか、AIの出力をどう修正したか、どこを理解していないかを見る必要があります。
AI時代の技術者育成では、成果物だけではなく、思考過程と検証過程が重要になります。
明日から始めるなら、この棚卸しからでよい
AIエージェント時代に向けて、IT技術者が今から始めるべきことは、特別なことばかりではありません。
まずは、自分の仕事を次の3つに分けます。
| 分類 | 例 | 扱い方 |
|---|---|---|
| AIに任せやすい作業 | 調査、要約、たたき台作成、テスト観点、ログ整理、文書作成 | 使ってよいが、出力は確認する |
| 人間確認が必要な作業 | 設計判断、レビュー、影響範囲判断、仕様決定、障害対応案 | AIは補助、人間が承認する |
| AIに直接任せにくい作業 | 本番変更、顧客影響のある判断、権限変更、重要データ更新、外部送信 | 原則として人間が実行する |
次に、AIが出した結果を検証する習慣を持ちます。
- コードならテストする
- 設計なら前提条件を確認する
- 文書なら事実確認する
- 運用手順なら実環境との差分を確認する
- セキュリティに関わる内容なら鵜呑みにしない
さらに、社内の情報整理に目を向けます。
- AIに読ませる文書は正しいか
- 設計書は更新されているか
- 運用手順は現状と合っているか
- 障害対応記録は再利用できる形で残っているか
- チケットの記述はあとから検索できるか
最後に、AIを使った作業のチームルールを決めます。
- AIで生成したコードは必ずレビューする
- AIが作成した文書には確認者を置く
- 機密情報は入力しない
- AIが参照した情報源を残す
- 本番操作はAIに直接実行させない
- AI利用時の判断はチケットやレビューコメントに記録する
これらは地味ですが、AIエージェントを安全に使うための土台になります。
技術者の価値は、作業量から判断の質へ移る
AIが進化しても、IT技術者の価値はなくなりません。
ただし、価値の中心は変わります。
単に手を動かしてコードを書く力だけでなく、目的を理解する力、構造を設計する力、リスクを見抜く力、品質を確認する力、関係者に説明する力が重要になります。
AIは、作業を速くします。
しかし、目的を正しく設定するのは人間です。
AIは、コードを生成します。
しかし、そのコードを採用してよいか判断するのは人間です。
AIは、膨大な情報を要約します。
しかし、どの情報を信頼するか決めるのは人間です。
AIは、障害対応案を提示します。
しかし、本番環境で実行するか判断するのは人間です。
AIエージェント時代に重要なのは、人間がAIと競争することではありません。AIを業務の中に組み込みながら、人間がどの判断を担うのかを明確にすることです。
AIに作らせることは、これから当たり前になります。
だからこそ、AIが作ったものを読めること。
AIに任せる範囲を設計できること。
AIの出力を検証できること。
AIが間違えたときに止められること。
AIを業務システムに安全に組み込めること。
ここに、これからのIT技術者の価値があります。
AIエージェント時代は、単なるツール導入の話ではありません。
開発、運用、セキュリティ、ガバナンス、人材育成を含めて、ITの仕事そのものを再設計する時代です。
今必要なのは、AIを恐れることでも、過信することでもありません。
AIを前提にした設計力を身につけることです。
作成日: 2026-06-30