「システム開発」といえば、大規模な要件定義書を作り、工程ごとに担当を分け、複数回のレビューを経て、数か月から数年かけて完成させるものでした。
その進め方がなくなったわけではありませんが、アプリケーション開発の実務はすでにAIエージェントを前提とする形へシフトしています。
AIエージェントは指示されたコードを補完するだけのツールではありません。
リポジトリ全体を読み、作業を計画し、複数のファイルを編集し、テストを実行し、結果に応じて修正し、レビュー対象となる変更をまとめる。
こうした一連の作業が、ひとつの連続した流れとして動くようになりました。
これは、これから訪れる未来の話ではありません。AIエージェントが開発工程の一部を実際に動かすことはすでに現場の選択肢になっています。
AIエージェントは「補助」から開発工程を動かす存在へ
「要件定義 → 設計 → 実装 → テスト」という工程そのものがなくなったわけではありません。変わったのは、それぞれを順番に一度ずつ通過する進め方です。
目的と受け入れ条件を伝えると、AIエージェントが実装案を組み立て、コードとテストを作る。動かした結果に違和感があれば、人が要件やUIを見直し、エージェントが再び実装と検証を進める。要件・設計・実装・検証を短い周期で往復する開発がすでに現実のものになっています。
人が一行ずつコードを書く時間は減っても開発そのものが不要になるわけではありません。
人に求められるのは、AIエージェントへ任せる範囲を決め、目的、制約、受け入れ条件を明確にし、結果が妥当かを判断することです。
「会議のあとに作る」から「その場で作って確かめる」へ
お客様の要望を聞きながらUIを生成し、既存のデザインシステムへ合わせ、APIとの接続方法を検討する。フィードバックを受け、その場で画面や挙動を変える。以前はプロトタイプの領域だったことが、いまは実装に近い精度で進められるようになりました。
ただし、画面が動くことと本番で安全に使えることは同じではありません。
データ設計、権限管理、例外処理、性能、監視、運用、保守まで含めて初めて、業務で使えるアプリケーションになります。
AIエージェントによって「形にするまで」は大幅に速くなりましたが、「安心して使い続けられる状態に仕上げる」ための設計と判断は今も欠かせません。
AIエージェントと小さなチームでより多くを動かす
AIエージェントが実装、テスト、ドキュメント作成、調査を連続して進めることで、少人数のチームでも扱える範囲は大きくなりました。
その結果、デザイナー、フロントエンドエンジニア、バックエンドエンジニア、テスト担当の境界は以前より近くなっています。役割が消えるのではなく、職種間の受け渡しが減り、ひとつのチームが判断から改善までを一気通貫で担う方向へ変化しています。
大人数で工程をつなぐことよりも文脈を共有した小さなチームが素早く試し専門家が要所を確認する。そんな開発体制現実的な選択肢になっています。
速く作れる今こそ、セキュリティが重要
AIエージェントはコードを提案するだけでなく、ファイルを変更し、外部ツールを呼び出し、テストやビルドを実行できます。行動できる範囲が広がったからこそ、誤った実装や危険な変更まで速く進めてしまう可能性があります。
存在しない、または古い依存パッケージの提案、認証・認可の見落とし、秘密情報の混入、過剰な権限、プロンプトインジェクション、CI/CD設定の意図しない変更など、AIエージェントを使う開発には従来の脆弱性に加えて新しい注意点があります。
そのため、AIエージェントが生成・変更したコードにも、人が書いたコードと同じか、それ以上に明確な品質ゲートが必要です。
- AIエージェントへ与える権限と接続先を必要最小限にする
- 本番の秘密情報から隔離された環境で実行する
- 依存関係、脆弱性、ライセンスを機械的に検査する
- 認証・認可、入力値検証、個人情報の扱いを人が確認する
- テストが通ったという事実だけで安全と判断しない
- 誰が変更を確認し、承認したかを記録する
AIエージェントが作ったから安全なのでも、AIエージェントが作ったから危険なのでもありません。 最終的な責任を持つ人を決め、権限、実行環境、検査、承認を含むセキュアな開発工程の中で使うことが重要です。
アクセシビリティはAIエージェントだけでは完結しない
アクセシビリティの分野でも、AIエージェントは力を発揮します。
HTML構造の解析、ラベル不足の検出、代替テキストの候補作成、コントラストの確認、テスト項目の生成、修正案の実装まで、自動化できる範囲は広がっています。設計や実装の早い段階から問題を見つけ、修正コストを下げることにも役立ちます。
一方で、アクセシビリティの多くは完全には自動判定できません。W3Cの評価方法でも、評価ツールを活用しながら、専門知識を持つ人による確認や、必要に応じた当事者の参加が重視されています。
たとえば次のような点は、現在も目視と実際の操作による確認が必要です。
- キーボードだけで迷わず操作できるか
- フォーカスの移動順や表示が自然か
- スクリーンリーダーで状態変化やエラーが伝わるか
- 拡大やリフロー時にも情報や機能が失われないか
- 見出し、リンク文言、代替テキストが文脈に合っているか
- 実際の利用者が目的の操作を完了できるか
つまり、AIエージェントによる自動検査・修正と、人による目視・操作・支援技術での検証はセットです。アクセシビリティを最後の検査項目にせず、要件、デザイン、実装、テストの各段階へ組み込むことが、これまで以上に重要になっています。
求められるのは、文脈と制約を与えられる技術者
これから評価されるのは、単にコードを速く書ける人や、プロンプトを上手に書ける人だけではありません。
「なぜ作るのか」「誰が使うのか」「何をもって完成とするのか」「どのリスクは許容できないのか」を整理し、AIエージェントへ正しい文脈と制約を与え、権限と品質ゲートを設計し、結果を検証できる人です。
技術者の仕事は、作業を抱え込むことから、AIエージェントと専門家を適切に組み合わせ、品質を導くことへ変わりつつあります。そして、正しさ、安全性、使いやすさに最終的な責任を持つのは、今も人です。
Liberogicとして
私たちリベロジックは、AIを導入すること自体を主目的にはしていません。
モダンなフロントエンド開発、複雑なAPI連携、UI/UX設計、アクセシビリティ対応で培ってきた知見を、AIエージェントへ与える文脈と制約に変換し、検証と改善の速度を高めています。
素早く形にする。実際に触って確かめる。そして、セキュリティ、アクセシビリティ、運用性まで含めて、安心して使える状態へ仕上げる。
速さと品質のどちらかを選ぶのではなく、より深い確認とより良い体験へ振り向ける。 それが、これからの開発に対する私たちの考え方です。
最後に
アプリケーション開発はすでに変わりました。
「人がすべての作業を抱える」工程から、
「人が目的と制約を示し、AIエージェントが実行し、人が確かめて責任を持つ」工程へ。
これから問われるのはAIエージェントを使っているかどうかではありません。
どこまで任せ、どの権限を与え、どこを人が判断し、どのように信頼できる品質へ到達させるかです。
社長でありながら常にカウンターパート。新しい技術を理解したり、何かが便利になる瞬間に喜びを感じ、ひたすら没頭する現場大好き人間。未来の技術にもわくわくしながら、いくつになっても新しい体験を楽しんでいたい。
森本さん
プロジェクトマネージャー / ディレクター / 2007年創業