こちらの記事は Medley Summer Tech Blog Relay の 9日目の記事です。
はじめに
株式会社メドレーの人材プラットフォームのSREグループに所属する稲村(@kzm0211)と申します。
最近、子供が週4でバスケ（ミニバス）🏀 をやっており私が送迎を担当しているのでなかなか土日ゆっくり休めず大変ですが、子供が色々なバスケの技ができるようになったり、シュートを決めたりしているのを見るのが楽しみになっています。
さて、今回は生成AIを活用した自動化に必要な権限設計の考え方について私が学んだことをお話ししようと思います。
こんな人が対象です
- SREチームに所属する人
- 生成AIを活用して自動化を進めている人
私たちSREグループでは、主な業務とは別に部署内の依頼業務を行っています。
- 入退職処理
- アカウントの権限変更
- インフラ環境の構築
などが不定期で発生します。
社内には実行するためのスクリプトなども用意されていたりしますが、歴史的経緯により、実行していたタイミングで権限が微妙に異なっていたり、APIキーの管理や実行環境の用意などを考えて結局人間が画面を見て判断してポチポチした方が速いとなり手作業が多く残っているというのが現状です。
最近では入社処理も多く、人手でやるのもなかなかに骨が折れます。
これらの定型的な作業のことをGoogleがトイルという言葉で定義しています。
トイルとは、手作業、繰り返される、自動化が可能、戦術的、長期的な価値がない、サービスの成長に比例して増加する、といった特徴を持つ作業です。
課題
SREをエンジニアとしてやっていると必ずと言っていいほどこれらのトイルが待っています。
SREでなくてもきっとこれらを担当されている方も沢山いらっしゃるでしょう。
これらを如何に効率よく自動化できるかはエンジニアとしての宿命かもしれません。
現代では生成AIが大変便利になってきており、弊社でもご多分に漏れず様々なところでの生成AI活用が進んでいます。
私も主にClaude Codeを業務に活用しています。
メドレーでは生成AI利用のガイドラインが社内で展開されており、各部門の業務ではそのガイドラインに沿って利用をしています。
日々業務をやっている中でどうしても不安としてつきまとうのが、生成AIに対する権限設計です。
強い権限で全部任せるのが一番楽ですが、インフラのような間違いでは済まされないようなオペレーションを伴う場合、何もかも生成AIに全て任せることは現時点ではまだ難しいと私は考えています。
しかしながら、何もかも難しいと言ってしまえば、自動化もできません。
役割を分担すれば生成AIでもできることはたくさんあります。
そこで、生成AIをうまく活用しながら、人間と生成AIで役割分担するためにはどうしたら良いかの設計概念として学んだことを共有できればと思います。
Separation of Duties(SoD)
まず、調べて知ったのが Separation of Duties(SoD)、日本語では職務分離です。
NISTでも定義されています。
職務分離とは、どのユーザーにもシステムを悪用できるほどの権限を与えてはならないという原則を指します。例えば、給与の支払いを承認する人が、給与支払いを準備する人であってはなりません。職務分離は、静的（競合する役割、つまり同じユーザーが実行できない役割を定義することによって）または動的（アクセス時に制御を強制することによって）に実施できます。
私も昔はCI/CDパイプラインツールで何もかも任せることが良いと考えていました。
シンプルだし、例えばGitHub Actionsだけを覚えればそれだけで完結できた方が、SREだけじゃなくて開発者も手を入れやすいだろうと思っていましたし、間違いではないと思います。
しかし、何もかもGitHub Actionsでやらせると、強い権限を渡さないといけません。
昨今ではサプライチェーン攻撃も盛んですので、強い権限を渡すことには大変なリスクを伴います。
SoDの考え方を取り入れた場合、1つで全て完結させることなく、作業や役割ごとに権限を分離してそれらが承認されて初めて成立するような仕組み化が重要そうです。
動的な職務分離の例としては、2人ルールがあります。2人操作を実行する最初のユーザーは、任意の承認済みユーザーであることができますが、2番目のユーザーは、最初のユーザーとは異なる任意の承認済みユーザーであることができます[RS Sandhu、P Samarati、「アクセス制御：原則と実践」、IEEE Communications Magazine 32(9)、1994年9月、pp. 40-48]。職務分離にはさまざまな種類があり、重要なものの一つに履歴ベースの職務分離があります。これは、例えば、同じ主体（役割）が同じオブジェクトに可変回数アクセスできないように規制するものです。
2人ルールの例としては、自作自演を防ぐためにGitHubのブランチ保護でPR作成者がマージできないとか、CI/CDデプロイパイプラインで、実行者が承認できないようにすることなどがあります。
ただし、この2人ルールでよくあるのがGitHubのマージ権限分離の場合に、マージできる人を偉い人に設定してしまうとMTGで不在にしがちなど、人数面がボトルネックになることがあります。
権限は役職単位ではなく、役割をベースに渡すといういわゆる RBAC（Role-Based Access Control）の考え方も重要そうです。
Principle of Least Privilege(PoLP)
最小権限の原則と言われる考え方です。
AWS Well-Architected というAWSが定義したベストプラクティスでもよく出てくる権限を付与する際の基本的な概念です。
必要な権限を付与しなければ、実行することはできません。
強い権限は作業が楽になるのは間違いではありません。
しかし、強い権限を持つことはリスクを伴います。
Human-in-the-loop(HITL)
処理の間に人間が関与するという考え方です。
ヒューマン・イン・ザ・ループ（HITL）とは、人間が自動化システムの操作、監督、意思決定に積極的に関与するシステムやプロセスを指します。AIの文脈では、HITLとは、人間がAIのワークフローのいずれかの段階に関与し、正確性、安全性、説明責任、倫理的意思決定を確保することを意味します。
人間が監視を行い、状況に応じて停止などを行うことは ヒューマン・オン・ザ・ループ と言い、AIだけで完結するようなもの（システム）は ヒューマン・アウト・オブ・ザ・ループ と言うらしいです。
今の自動運転などがそれらの考え方にあたるようです。
つまり、HITLは全てを生成AIに任せないという考え方です。
ものによっては全て任せた方が早いし楽だとは思いますので、対象システムの要件次第でどこまでを任せるか設計するのがキーになりそうです。
Capability-based Security
必要な操作の鍵だけを、その実行の時だけ渡すという考え方です。
概念的に少し難しいですが、自動化の時であれば特定の権限だけがあるAPIキーを都度発行して実行させるようなイメージでしょうか。
AIに必要な権限を必要なだけ継続的に渡すのではなく、人間が承認したときだけ必要な分の鍵が期限付きで発行されるという構図にするのが安全になります。
そんなことを調べていたところ下記の資料を見つけました。
分散システムにおけるCapabilityを用いた資源アクセス制御
ここでは、Confused Deputy Problem（混同された代理人問題）についての記載があり、権限を持つプログラム（代理人）が不適切な制御によって意図しない情報漏洩や操作を行ってしまう問題があり、これを解決するために Capability方式の有効性を指摘しています。
AWSに関する自動化のシステムをGitHub Actionsで実装した場合の方法としては、下記のようなアーキテクチャになりそうです。
[GitHub Actions ワークフロー]
│ 1. 「タスクX を実行したい」とだけ申告
│ (OIDCトークンで身元を証明するのはここ1回だけ)
▼
[Token Vendor (Lambda / API Gateway)] ← ここが論文でいう ADF + 発行所
│ 2. タスクXの定義台帳を参照し、
│ 「必要な操作・対象リソース・有効期限」を決定
│ 3. その内容を session policy として焼き込んだ
│ 一時クレデンシャル（or presigned URL）を発行
▼
[ワークフローは受け取った鍵で作業実行]
│ AWS側 (AEF) は鍵に焼き込まれた範囲しか許可しない
▼
[数十分で自動失効]
なかなか難しい実装ですが、これであればガードレールをAWS側に持たせることである程度制御することもできそうです。
AI Guardrails
すでに多くの生成AIに標準の機能としてありますが、AIに対して何をさせないかという定義を行うことです。
個々人の生成AIの設定だけではなく、生成AIじゃない別のレイヤーでGuardrailsを導入することで、生成AIが暴走した時にしっかりと防ぐという考え方もあります。
CASBで有名なNetskopeでもAI Guardrailsを謳った製品が出ていたりします。
多層防御の考え方とも近いものがあり、生成AIが実行していないレイヤーで止めるということも考えた方が良さそうです。
生成AIには参照しかさせたくなかったのに、削除作業までされてしまったというのはよくある話です。
私もプライベートで大量のファイルの移動を生成AIに任せていたところ、日本語処理が甘く、ファイルをうまく移動できていないにもかかわらず、コピー完了と同時にコピー元を削除されてしまったことがありました（バックアップデータから目視でリストアする羽目になりました）。
移動だけお願いしていたのにまさか移動が正常に行われていなくても削除するなんて思わず、久しぶりに痺れた出来事でしたが、まさにAI Guardrailsで削除は禁止にしていれば良かったかもしれません（とは言え、ゴミを残さないでほしいという気持ちもあったりします）。
AI自律性レベル
Googleのドキュメントに Google SRE「AI 自律性レベル」 というのがあります。
Engineering Reliable Operations with AI (Google SRE)
ここでは、自動運転のアナロジーで SRE 運用の自動化レベルを L0〜L4 の5段階で定義しています。
| レベル | 名称 | 内容 |
|---|---|---|
| L0 | Manual | すべて人間主導 |
| L1 | Assisted | 監視・調査は自動、承認・実行は人間 |
| L2 | Partial | 実行まで可能だが人間の明示的承認が必須 |
| L3 | High | 定義済みシナリオでは承認不要で自律実行 |
| L4 | Full | 複数ステップの診断・緩和・解決まで完全自律 |
まずはL1から検討し、L2、L3あたりをめざすのが良いのではないかと思います。
これらを踏まえて
まずは我々のチームでは以下のような非常にシンプルな仕組みから導入しています。
- 事前に参照、作成、削除、ドライランが行えるスクリプトを用意
- 生成AIのSkillsによりGitHub issueを読み取って、実行手順を出力（生成AIには実行させない）
- 人間がそれを確認して、問題がなければ手元から実行する
Separation of Duties(SoD)とAI Guardrails
AIがissueを読み取って実行するコマンドを提案し、人間はそれを見て問題なければ実行する。
これはまさにSeparation of Duties(SoD) の概念です。
これにより人間は作業マニュアルなどを見たり、余計な分岐を頭で巡らせなくても、コマンドを実行するだけでOKです。
シンプルなAI GuardrailsをSkillsに記載することで、生成AIがコマンドを実行することはまずありません。
AWS CLIを実行するスクリプトであれば、ログインセッションの有無をチェックするようにするのも小さなガードレールになるでしょう。
Human-in-the-loop (HITL)
また、作業の間に人間が入り、最終的に実行するのは人間です。
これもHuman-in-the-loop (HITL) の概念です。
自動化が進めば人間は承認だけで良くなるHuman-on-the-loopまでいけるかもしれませんが、マネージドサービスにどこまでの権限を渡すかの懸念はあります。
結果
これらにより、まだ一部ではあるものの特定の作業においては、人間はただ最後にコマンドを数行実行するだけで良くなりました。
人間が考えて分岐を選択していくという作業が減っただけでもかなり楽になりました。
課題感としては手元の実行履歴が残りにくいというのが挙げられます。
各種コマンド実行の多くがAPIリクエストを伴ったものになるので、クラウドにおいては基本監査ログで取得できますのでほとんどは問題がありませんが、SaaS系サービスはプランによっては監査ログまでは取得ができないなどの課題が残るでしょう。
今のところは間に人間が入ることでうまくいっていますが、完全な自動化をめざすにはSoDでレイヤーごとにアーキテクチャを用意するのが良いのではないかと模索しているところです。
SoDごとに階層構造で構築し、それぞれを独立した権限にするというのが良いのかもしれません。
結局はコンテナやマイクロサービスのような概念に収まっていくのが今のところの解なのではないかと考えています。
SRE本における「自動化のすすめ」の章でも
自律的な運用を大規模なシステムに確実に対応させるのは難しいことですが、サブシステムの分離、APIの導入、副作用の最小化といったソフトウェアエンジニアリングにおける標準的な優れたプラクティスは、非常に役に立つのです。
引用: オライリージャパン. サイトリライアビリティエンジニアリング. 7.8 自動化のススメ P89
といった、そもそもの信頼性を高めることの重要性を説いており、生成AI時代でも有効であり不変な考え方だと感じました。
最後に
非常に単純な一部の自動化からのスタートではありますが、改めて設計思想を踏まえて考えると自分の中でも腑に落ちました。
また、それぞれの業務の自動化レベルが生成AIを踏まえてどのレベルにあるか、理解が容易になりました。
生成AIが出てきたことで、完全自動化はアーキテクチャを作成するという点においてはやりやすくなりましたが、逆に全てを任せることに対するリスクが格段に上がっているでしょう。
そのための設計力も重要になってきているとも言えますし、まさにエンジニアが今後求められる部分になるのではないかと感じました。
これらの考え方をもとにより生成AIをうまく活用していけると良いかなと思います。
今回はあくまでも私が学んだことなので、より良い考え方や手法がありましたらぜひお教えいただけると嬉しいです。
次のMedley Summer Tech Blog Relay 10日目の記事は藤原さんです。
We are Hiring!
メドレーでは一緒に働く仲間を募集しています！ご興味のある方、ぜひご連絡をお待ちしております。