AIセキュリティエンジニアが1年で得た4つの洞察
この1年で、AIの世界は大きく変わりました。とりわけ変化が大きいのはモデルの性能です。1年前、私たちはGPT-4の登場に驚いていましたが、いま振り返ると当時の性能はどこか原始的にも見えます。主な用途もラフな文章生成や要約といった領域が中心でした。
しかし時代は移り変わりAIの世界は単なるLLM API呼び出しを活用した多段ワークフローから、MCP、ツール、スキルなどを用いて複数ステップを自律的に実行するAIエージェントへ、そしてさらに複数のAIエージェントがA2Aやエージェントプラットフォーム上で協調して動作する世界へと進化しつつあります。
事業会社のAIセキュリティエンジニアとしてこの1年間さまざまなAI関連製品の導入、社内でのAI活用のセキュリティの立場からの推進、AIエージェント開発に深く関わってきました。その中で、これらの本質や必要なスキルについて考え続けてきた立場から、AIに関わるセキュリティエンジニアおよびAIを使いたいと思う方・戦略決定を担う方へ以下の4つの洞察を共有します。
- 1ヶ月待つ努力を惜しまない
- AIエージェントの変数は4つであることを認識する
- 基準を決める覚悟を持ち、妥協せずにその基準を変える
- 未来の方向性と時間軸を把握し続ける
この洞察は今後のAIエージェントの動きに対しても同様に当てはまり続ける部分があるはずです。
1. 1ヶ月待つ努力を惜しまない
現在、AIに関する新しい製品のアップデートやリリース、次世代トレンドがさまざまなソーシャルメディアで共有されています。利用者側の視点に立てば、Early Adopterとして新しい製品を試し、そこから新しい知見を得るのは素晴らしいことです。ただ一方で、それを特定の組織で利用可能にする試みには、ある程度の慎重さが必要です。
なぜなら、LLMのプロバイダーは数多くある一方で、動作原理はどれも本質的に同じだからです。入力に対して次の単語を予測するという点は変わらず、基本的には入出力の方式などを調整したにすぎません。そのため過去1年を見ても分かる通り、画期的なAI製品が登場しても、数週間〜数か月後には競合他社からほとんど同様の製品がリリースされる状況が長く続いてきました。さらに「新製品」と銘打たれていても、実態はシステムプロンプトを変更しただけで、すでに導入済みの製品群で再現できるケースも多々あります。
加えて、新しいAI製品の導入には大きなコストが伴います。予算といったお金の問題だけでなく、利用者のコントロール、セキュリティ対策、監視・監査体制の構築、利用ルールの調査と徹底など、従来のサービス導入と同様に、さまざまなリスクを低減するための管理が不可欠です。さらに、一度導入した製品を終了するにも非常に大きなコストがかかります。新入社員へのアカウント配布や棚卸し、定期的な予算調整、随時アップデートされる機能への追従、そしてそれに伴うセキュリティガイドラインの更新。こうした運用コストを払い続けるに値するかも、あらかじめ精査する必要があります。
つまり、画期的なAI製品の導入を決め、さまざまなコストをかけて調達・利用可能化のプロセスを踏んだとしましょう。それでも、次に競合他社がより優れた製品を出してくれば、その努力は水の泡になりかねません。これを踏まえると、実験の場は設けつつも、本格導入にあたってはやはり1か月待ち、そこで本質を見極めることが重要です。既存の導入済みAIという資産と比較しながら、組織として確実にメリットが得られる製品、あるいは独自開発を進めるべきものを選ぶべきです。
この1年間、多くの新規AI製品の機能リリースを見てきた立場からすると、ほとんどのAI製品の中で、真に画期的で導入に値するものはごく少数でした。一方で、ソーシャルメディアの新しいトレンドに追い回され、そうした本質を見極める目はこれからだという人も少なくありません。そうした人たちと適切にコミュニケーションを取りながら、組織として確実にメリットが得られるAIを取捨選択する責任は、AIセキュリティエンジニアに不可欠です。
とはいえ、AIセキュリティエンジニアは非常にプレッシャーの大きい現場に立たされています。トップダウンでのAI導入や、メンバーからの新規AI機能の利用可否判断の依頼に加え、日々の業務にも追われる中で、持ち込み型の仕事を数多くこなすには周囲の理解が不可欠です。だからこそ「1ヶ月待つ努力を惜しまない」というメッセージが、AIセキュリティエンジニアだけでなく、AI活用に取り組む他のメンバーにも広がっていくことを切に願います。
2. AIエージェントの変数は4つであることを認識する
先ほどの章で述べた通り、LLMの動作原理は変わっていません。一方で、MCPやA2A、Agent Skillといった新しい概念が登場し、CLIツールが流行したり、MarkdownではなくHTMLが注目されたりと、さまざまなトレンドがソーシャルメディアを賑わせています。
しかし技術的な本質に立ち返ると、AIエージェントというジャンルでは、目的の異なる多くの製品が存在していても、AIエージェントを形作る変数は4つに絞られると考えています。すなわち、
- 入力
- 出力
- ツール
- システムプロンプト
です。
ここでいう入力とは、たとえばChat UIにおける最初の問いかけや人間による返答、スケジュール実行時の起動メッセージ、あるいは特定のアラートに反応して起動するSREエージェントにおけるイベント駆動型の入力を指します。
出力は、LLMを介して生成される自然言語や構造化データとその形式です。
ツールは、MCPに代表される関数呼び出し機能であり、外部API連携、ファイルシステム操作、コマンド実行などを可能にします。
そして最後のシステムプロンプトは、AIエージェントの動作を定義する従来のシステムプロンプトに加え、エージェントスキルのように動的に読み込まれるものも含みます。
これら4つの変数によって、AIエージェントは基本的に形作られています。もちろん、LLMモデルの選択、実行基盤としてのプラットフォームや、そこでのオーケストレーション方法、セキュリティ対策も、ある意味では変数の一つです。ただ今回は、エージェントの基本的な動作原理に絞って述べます。
この4つの変数を自由に組み替えられるようにすることこそが、エージェントプラットフォームの最終的なゴールであり、世の中のAI製品はこれら4つの変数を特定の目的のために固定化したり、選択可能にしたりしているにすぎません。
裏を返せば、新しいAI製品に憧れて使い始めたものの、実際に使ってみると期待ほど満足できず落胆してしまう人の多くは、この4つの変数を十分に把握できていません。「どの変数にどんな値を選ぶと、どんな結果が得られるか」という経験が少ないため、製品の見た目や謳い文句に引きずられて、期待だけが先行してしまうのです。
逆にこの「4つの変数」という切り口さえ押さえておけば、これから新しく登場するAI製品の見極めにも、エージェントプラットフォームの選択にも、さらには未来の方向性を予測するうえでも、強力な羅針盤になるはずです。
3. 基準を決める覚悟を持ち、妥協せずにその基準を変える
これは特に、AIやAIエージェントの新機能に対して、セキュリティエンジニアがどのような姿勢で向き合い続けるべきか、という観点の話です。
1年前、LLMにおける主な性能向上テクニックはプロンプトエンジニアリングでした。どのようなシステムプロンプトを用意し、どのように入力を与えるかといった、「LLM API呼び出しでいかに精度を上げるか」が主戦場でした。
しかしその後、AIエージェントの登場と、AIエージェントワークフローやA2Aなどの可能性追求が進んだことで、Context Engineeringがプロンプトエンジニアリングに取って代わりました。以前のようにLLMのAPIを呼び出すだけの世界では、たとえば個人情報の利用や、出力データの正確性、プロンプトインジェクションといった、基本的なLLMセキュリティが主な論点でした。つまり、AI製品を導入する際はまずその点を中心に考えればよい、という前提が成り立っていました。OWASP LLM Top10は、まさにLLM時代を代表するセキュリティガイドラインの1つでした。
一方で、AIエージェントが自律的にファイルシステムを読み書きし、自由にコマンドを実行し、外部APIを呼び出す現在では、セキュリティの基準が大きく変わります。もちろん、これまでの基準を遵守することは重要です。ただし、基本は変わらなくても求められる基準は移り変わり、過去の基準が新たな世界でのスタンダードではなくなる可能性がある点に注意が必要です。実際に現在最もよく私が参照するガイドラインはOWASP Top 10 for Agentic Applications for 2026になりました。
ここで、過去に策定した基準を改定したり、あるいは今までは許可していなかったAIの使い方を許容したりする必要が出てくるでしょう。セキュリティエンジニアは安全に対して責任を持つがゆえに、多くの場合「現場がやりたいことのブロッカー」となり得ます。新しいAIの使い方や、AI製品の導入・利用方法に関する現場からの要求に対して、どうしても危険性に目が向き、阻止したくなるものです。
しかし一方で、組織へのAIの浸透が経営課題になるほど強くAI推進を行う必要がある現在、セキュリティチームがブロッカーとなることは、経営上のリスクの一つだと捉えられかねません。この場合、AIに関わるセキュリティエンジニアはマインドセットを変える必要があります。つまり、ブロッカーではなくイネーブラーとして、どのようなルールやセキュリティガードレールを用意すれば、新しいAI製品や新しいAIの作り方・使い方を許容できるのかを真摯に考える必要があります。
そのためには、セキュリティエンジニアは単にAIの安全性や危険性を把握するだけではなく、どのようなAI利用が行われているのかを最新情報をキャッチアップしながら理解したうえで、さまざまなステークホルダーと粘り強くコミュニケーションすることが求められます。
このように、安全にAIを利用可能にするスキルは非常に希少性が高く、そのスキルを持つことは、今後セキュリティエンジニアとして生き残っていくために欠かせません。
4. 未来の方向性と時間軸を把握し続ける
また、最新情報を追うだけでなく、これまでキャッチアップしてきた変化の蓄積から未来を想像することも必要です。
「方向性」：過去の革新と重ねて未来を見通す
現在、LLM関連の技術は非常に速いスピードで進歩しています。方向性としては、クラウドが「前提」になっていったのと同様に、技術が発展し、成熟し、組織化され、ベストプラクティスが整備されていく過程にあると考えています。
ここで過去の技術的革新に目を向ければ、AI技術の発展方向もある程度は見通せます。現在盛んに議論されているエージェントプラットフォームやエージェントサンドボックスは、まさにクラウドが辿ってきた道に重なります。ゼロトラストの概念がAIエージェントにも入りつつあるのも、その延長線上でしょう。このように、過去の革新の歴史から未来を想像し、その方向性を把握し続けながら、どのようにAI推進を行うべきか、技術選択を真摯に考え続ける必要があります。
現在のAI活用では、社内外向けのプロダクトが量産され、試行されています。しかしその一方で、大手LLMプロバイダーの類似製品の登場によって利用されなくなったり、社内で使っていてもすぐに技術的に陳腐化したり、内製AIが無秩序に増えることで維持管理コストが重くのしかかったり、管理体制の見えにくい部分が増えたりと、課題も山積しています。
これらの課題は、オンプレミスでサーバーを手動管理していた時代から、Ansibleによるコード化を経て、クラウドが機能を提供し、IaCで管理できるようになっていった「初期状態」にAIがあることの裏返しでもあります。
これから先、向かうべき方向性を見定めるうえで、各社から登場する多様なプロダクトを適切に取捨選択するのも、セキュリティエンジニアの責任の一つです。安全性についても同様に、過去の技術発展のタイムラインに沿って向上していくと私は考えています。その前提に立ち、適切な製品選定や技術選択を支えることが不可欠です。
「時間軸」：浸透までのリードタイムとROI
技術的発展にかかる「時間軸」を意識し続けることも、同じくらい重要です。いまRFCなどで議論されているOAuthの次期仕様やエージェントアイデンティティの要件を例に考えてみてください。これがプロトコルとしてまとまり、利用例やPoCが普及し、大手サービスプロバイダーにまで浸透するには、どれほどの時間がかかるでしょうか。
つまり、利用可能になるまでに時間がかかる領域については、方向性と理想を見据えつつも、当面は手元にある道具で解決していく必要があります。そして「手元で解決する」ためには、開発コストとメンテナンスコストが確実に発生します。将来それを代替するソリューションが何か月後、何年後に現れうるか。この見立てまで含めて、安全性を担保しながらROIを計算することが必要不可欠です。
安全性だけを理由にしない
セキュリティエンジニアがこうした方向性や技術選択の議論に、単に安全性だけを理由に参加しても、周囲の理解を得るのは難しいでしょう。技術的方向性として大きなメリットがある選択肢を、「安全ではない」の一言で切り捨ててしまうのは、あまりにももったいないからです。
いまAI領域という不確実性が高く発展途上の分野で求められるのは、確実な勝ち筋を方向性と時間軸という2つの方向を掴んだうえで全体として捉え、それを推進できる能力です。この考え方がAIに関わるセキュリティエンジニアだけでなく、AI領域の推進を担う方にも伝われば幸いです。
最後に
やや抽象的な内容にはなりましたが、AIセキュリティエンジニアとしてこの1年働く中で、今後も活躍し続けるために大切にしている4つの洞察をお伝えしました。
今回はAIという技術領域の中でも、とくにSecurity for AIに絞って述べましたが、これらはほかの技術領域にも当てはまると考えています。脆弱性診断のAI化、SOCのAI化、クラウドのインフラ管理のAI化など、既存のセキュリティ領域でも技術的な進展は続いています。
ここで紹介した考え方はAIに限らず、ほかの領域にも適用できるはずです。ぜひ参考にしていただき、より多くの方が安全なサービスの提供と、そのサービスを安全に利用できる環境づくりに取り組めることを願っています。