Red HatのAnsibleのAPACリーダーにインタビュー。オートメーションのAI化とは？
レッドハット株式会社は2024年8月7日、インフラストラクチャー構成管理のツールのAnsibleに関する半日のイベントAnsible Automates 2024を都内で開催した。それに合わせて来日したアジアパシフィックリージョンのAnsibleマーケティングチームのリーダーであるCharles McClelland氏にインタビューを行った。McClelland氏のタイトルはAPAC Automation Platform Leaderというもので、シンガポールからAPAC全体のAnsibleのテクニカルマーケティングをリードする役割だという。
簡単に自己紹介をお願いします。
McClelland：私はAPAC全体のAnsibleのテクニカルマーケティングのリーダーとして、2024年2月にアメリカからシンガポールに移って活動をしています。これまでオートメーションのソリューションについてはアジア各国でバラバラに活動していましたが、このチームができたことでパワーアップした感じになっています。現在はAPAC全体で25名のグループとなっていてテクニカルなセールスサポートを行うエンジニアの組織です。Ansibleの顧客向けのテクニカルサポート、コンサルティングは別途に存在します。私個人のキャリアとしてはアメリカの海兵隊に入隊して、そこでInfantry Officer（海兵隊将校）としてアジアに赴任した後でITシステムのインストラクターとして仕事をしていました。その後にIBMでマーケティングの仕事をしたのち、Red Hatに移りました。
海兵隊というとあの海兵隊ですか！？ 我々が良くハリウッドの映画で見るような激しいブートキャンプがある？
McClelland：そうです。まぁ、その頃は若かったからできたことかも知れませんね（笑）。
インタビューを受けるCharles McClelland氏
今回はAnsible Automatesというイベントのために来日したわけですが、イベントの感想は？
McClelland：半日のカンファレンスに多くのお客様が参加してくださって大変うれしく思います。オートメーションが実際に日本でも定着しつつあることが実感できました。
生成型AIはRed Hat Summitでも中心的なトピックでした。Red Hat Enterprise Linux（RHEL）とOpenShiftそしてAnsibleにAIが搭載されるということを繰り返し訴求していましたが、Ansibleは他の2つよりも早く生成型AIが実装された製品になりますよね。しかし生成型AIにとっての大きな問題であるハルシネーションの排除について、Ansible Lightspeedでできるのかを教えてください。一つのモデルに依存してハルシネーションが起こるのであれば、複数のモデルを使って合議制でAIが回答を評価し合うという方向に行って欲しいと思いますが、それについては？
McClelland：ハルシネーション、つまりAIが間違った答えを回答してしまうという問題ですが、これについてAnsibleはガードレイルを使ってそれを抑制しています。そのガードレイルはPolicy as Code、つまり生成される構成管理のためのコードが企業のポリシーに沿っているのかを確認するというやり方です。
一般的には生成型AIが間違った答えを出すという問題については多くのアプローチがありますが、どれもこれが正解という解決策はまだ作られていないというのが現状でしょうね。ただし複数のモデルを使ってより正しい回答を生成するというのがコンテナセキュリティですでに実装されている方法論だと思います。つまりある脆弱性スキャナーで発見できなくても別のテクノロジーを使ったスキャナーを使って脆弱性を発見するという発想です。
Ansibleについては2つの方法でハルシネーションを抑えることができると考えています。1つ目の方法はキュレーション、つまり正しい構成情報をより多く使うことで間違ったプレイブックを生成させないという方法、2つ目はアトリビューション、これは生成された構成情報が何をソースとして作られたのかという属性を明らかにするという方法です。ここまではすでに実装されている機能ですが、さらに今後の方向としてLightspeedが生成する構成情報のソースとしてプライベートオートメーションハブというリポジトリーを使うことが計画されています。これによってパブリッククラウド等に構成情報を露出させずに、社内のリポジトリーに閉じた形でその企業の基盤に特化した形の構成情報が生成できるようになります。
もう少し自動化を進めるとAnsibleのCode Botを使ってプレイブックが変更されるたびにAIがチェックを行い、自動的に推奨されるコードに変更するプルリクエストを生成する機能なども用意されています。
生成型AIを使うことの効果についてはいろいろな企業が訴求していますが、Ansibleオートメーションという視点から言えば、3つに集約されます。まずはデベロッパーの生産性が上がること、これはMicrosoftやGitHubのCopilotを見ればわかりますが、マニュアルでコードを書くよりも素早くコードを生成することが可能になっています。もう一つは品質が上がることですね。これは多くの構成情報はすでに検証済みのコードですから、それをベースに新しい構成を作ること自体の品質が上がります。そして最後は、インフラストラクチャーの構成を作るエンジニアの数が10倍以上になることです。これはあまり注目されていないポイントですが、Lightspeedでプレイブックを書くことによってこれまでインフラストラクチャーやミドルウェアの設定をやったことがなかった人でもそのタスクをこなすことができるようになることを示しています。
GitHub UniverseなどでGitHubが盛んにアピールしていたのは単にプログラムコードを書くペアプログラマーとして使う以上にプルリクエストのコメントを書いたり、ドキュメントを書いたりというこれまでデベロッパーがやらないといけなかった難しくはないが面倒くさい仕事を任せることができるという点でした。Lightspeedにもそういう機能は実装されますか？
McClelland：現在、自然言語でプレイブックの内容を解説させる機能はテックプレビューとして公開されています。運用的な視点ではこの構成でセキュリティリスクはどのくらい発生するのか？ これを生成型AIに説明させるという使い方も考えられます。同様に「この構成だとコストはどのくらい上がるのか？」という使い方もできますね。ブルーグリーンデプロイメントであれば当然、実行に必要なインフラストラクチャーは2倍になりますので、それを生成型AIに発見させてそのコスト増に見合う効果があるのかを人間が判断するという使い方です。
GitHubの話が出たのでGitHub/MicrosoftとRed Hatの違いを簡単に説明しておきましょう。GitHubがペアプログラミングのソースとしているのは彼らが保有する大量のオープンソースコミュニティのソースコードです。当然、使っている言語にも違いがありますし、開発しているプログラマーの習熟度もバラバラです。しかも生成されたコードが何を使っているのかというアトリビューションを確認することは難しいと思います。
一方Ansible Lightspeedは、オートメーションハブや企業内で使われているプライベートオートメーションハブに存在するプレイブックの内容から学習しているので、そのコードの由来を確認することができます。
ここまでキュレーション、つまり多くのコントリビューターが参加することでモデルの品質が向上することを訴えてきましたが、xz-utilsに発生した脆弱性のように悪意を持った攻撃者が良いコントリビューターを装って2年近く活動してきた後に突然、悪意のあるコードを混入させるということが起こりました。Linus Torvalds氏が言う「given enough eyeballs, all bugs are shallow」というルールが覆されそうになっていることを感じます。Red Hatがサミットで発表したInstructLabもその発想に基づいていると思います。これについては？
McClelland：確かにInstructLabも当初は品質があまり良くありませんでしたが、多くのキュレーションが行われたことで品質が向上したことを体験しています。悪意を持った人間が辛抱強く待った後に攻撃を行ったとして、それを直すために多くのエンジニアが参加していることで修正はかなり短い時間の内に行われます。ですのでキュレーションが意味を持たないとは思いませんね。
ではAIの話題を離れてオートメーション、Ansibleの話をしましょう。現在の課題は？
McClelland：APACの各国で違いがありますが、企業の中でオートメーションが進んでいることは実感しています。特にここで話題として挙げたいことが2点あります。最初はTerraformを持つHashiCorpのIBMによる買収発表についてです。これはまだ完了していないので今の時点で最終的にどうなるかは予測できませんが、製品のポートフォリオとしてはお互いが補完する形になると思いますね。実際に多くのエンタープライズ企業がDay1のオペレーションにTerraformを使い、Day2以降のオペレーションにAnsibleを使うというやり方が多く見られます。
もうひとつはシークレット管理のVaultです。Vaultは多くの企業が持つ悩みの種、多様なインフラストラクチャーやミドルウェア、データベースに付随するクレデンシャルをどうやって管理するのか？ これに対する回答となっています。この買収によってクレデンシャル管理がさらに密接にオートメーションのソリューションに連係することを期待しています。
良くある批判の一つに、シークレットが一ヶ所で集中管理されることでハックされたら多くの被害が発生するというリスクを指摘する人もいます。しかし、弱いパスワードがシステムの中で散在するよりも遥かに良いソリューションです。
クレデンシャル管理について日本のITの問題点の一つに大きく関わっていると思う点があります。それは企業がシステム開発を行う時に外部のリソースを使わなければ実行できないという問題です。特にエンタープライズ企業であれば社内のIT部門はシステムの設計には関わるものの、その開発の段階では外注化され多くの外部ベンダーのエンジニアが社内に常駐して行うことが発生します。その時に社員と入れ替わりが激しい外部のエンジニアをどうやって管理するのかというのが問題点になっています。その際にVaultが使われるとしても管理は煩雑になります。
McClelland：Ansibleではそこを独自に解決するのではなく、企業がすでに持っているアイデンティティ管理のツールと連係することで解決をするようになっています。例えばActive Directory（AD）を中心として使っているのであれば、ADと連係することがAnsibleの役目になります。また構成管理という部分では企業がプライベートオートメーションハブというリポジトリーで管理することに加えて、プライベートパートナーハブという外部ベンダーのためのリポジトリーを持つことも可能です。ここで自社のエンジニアと外部パートナーのエンジニアがタッチできる構成管理ファイルに分けて管理できます。またリポジトリーに対してデジタル署名を加えることで開発段階ではさまざまな試行としてサインされていないプレイブック、つまり外部の外注先のエンジニアが作ったものでも実行できますが、ステージングや本番環境においては認定されたデジタル署名が加えられたプレイブックだけが実行できるという住み分けが可能です。このように複雑な構成となっている開発チーム、運用チームでも対応できるようになっています。
日本のエンタープライズ企業でも内製化が進んでいることを感じますか？
McClelland：それは感じますね。今回のカンファレンスでも多くの国内の企業が内製化にチャレンジしているという発表がありました。製造業から金融機関までこれまで保守的だと思われていた企業でも、内製化によって自動化を進めようという意図は感じています。
レッドハット株式会社の受付にある盆栽の前でポーズ
元海兵隊の将校だったというキャリアを持つMcClelland氏には、AI_devやKubeConなどで多くの専門家に「ハルシネーションを抑制するにはどうするのか？」という質問を投げたが余り的確な答えが返ってこなかったことを伝えたら「一番正しい答えは『I don't know』だと思う」というコメントを返してくれたのが印象的だった。ちなみに好きな日本食は焼きそばだそうだ。
カンファレンスについては下記公式サイトを参照して欲しい。
