最近の記事

IaCとCI/CDは何を達成すればよいのか? 導入検討にあたってすべきこと、さけるべきこと

概要と背景

かつて先進的な取り組みであったIaCやCI/CDも昨今はさほど珍しいものではなくなりました。その有益性が実感されていればこそでしょう。DORAのサイトにおいても、“Infrastructure-as-code allows you to manage changes effectively, and to apply information security controls. “と述べられるように、効果的かつセキュアな運用にIaCやCI/CDは大きく貢献します。

しかし具体的にどのようなメリットがあるのかを改めて説明しようとすると意外と難しいものです。そこでこの機にまとめなおしてみました。

og

DevOpsにつきもののCI/CD、そのメリットとは?

なぜIaCとCI/CDを用いるのか。得るべきそのメリットとは。

IaCとCI/CDのメリットをそれぞれ整理したのが以下の表です。

IaC(Infrastructure as Code)のメリット

区分具体的な利点説明
再現性同じコードから何度でも同一環境を構築可能設定漏れや設定ミスの発生を抑止し、環境差異の極めて少ない環境構築が可能になります。
可読性・共有性インフラを設定で可視化できる必然的に設定が明文化されるため、知識が属人化しにくくなります。
バージョン管理Gitでバージョン管理できるインフラをGitで管理できます。変更を追いかけるロールバックも容易です。
モジュール化による再利用共通コードで省力化何度も利用する設定をモジュール化して使いまわせば効率よく構築できます。設定ミスがおきづらいことから信頼性も高いです。
ツールの利用静的解析でチェックできるcheckovなどでコードレベルでインフラの構成をチェックできます。

実はIaC(インフラのコード化)単体ではメリットを出しづらく、多くはほかの施策や技術と組み合わせることで効果を発揮します。

例えば、再現性や可読性、モジュール化による再利用はそれを可能にするコードを書いてこそ機能します。バージョン管理はGitを導入・運用していなければなりません。静的解析のツールも同様です。

IaCの導入とは、ただTerraform(あるいはCDKやCloudFormation等)を用いるだけではなく、その他のツールや技術も合わせた総合的な施策なのだと言えます。

CI/CDのメリット

区分具体的な利点説明
自動化による信頼性向上plan -> (approve) -> apply を自動で実行できる作業ミスやメンバーごとの手順の違いなどを抑止します。運用の信頼性を向上させます。
テスト・チェックの確実な実行静的解析やterraform planなどを自動実行できるチェック忘れがなくなります。手動で行っているとフォーマッタやテストツールの実行を忘れるのも日常茶飯事です。
ガバナンス強化レビューと承認フローを必須にできるterraform planの結果とApprove機能のことです。Githubの機能と組み合わせるとさらに強力です。雑な仕事、悪意ある(!)作業を抑止できます
証跡保存コード変更・CI 実行ログが残るログがチーム共用の場に残るため追跡が容易になります。
アクセス権の保護権限をクラウド上で集中管理できる普段はCI/CDで更新するようにしておけばメンバーが普段から強すぎる権限を持たずに済みます。ただしブレイクグラスや、そこまでシビアでないならAssumeRoleなど、臨時作業の手段も用意しておく必要があります。

CI/CDの売りはなんといっても信頼性の向上です。昔から業界には作業漏れや作業ミスの笑い話(?)が絶えません。しかし自動化した部分については――自動化でミスしていれば別ですが――そのような問題を抑止することができます。逐一手順書をかかずに済むなど、本番作業の省力化に繋がることもあるでしょう。またミスのリカバリ作業が減ることからコストメリットも副次的に生じるかもしれません。

DevOps

AI連携エディタ利用を安全にする専用ユーザー作成のすすめ(Windows11)

AI連携エディタは開発作業を効率化できる便利なツールですが、機密情報をうっかり渡してしまわないよう注意する必要があります。AI連携エディタが利用したデータは外部のAIサービスへ送信されているためです。「AI連携機能を利用する」=「外部に情報を送信する」なのです。

機密性の低い情報に対してまで必要以上に警戒すべきとは言えません。それによって効率性を損なうことは別の問題を生じます。また現実問題として外部送信程度なら許容できるケースも多くあることでしょう。しかしAPIキーや顧客の個人情報などの機密性が極めて高い情報については話が別です。このような情報は送信してしまうだけで問題、まして悪用されたとなれば大問題です。ちゃんと外部AIに学習させない設定を有効化していれば外部AIに送った情報は流用されないはずですが、完璧とは限りません。AI連携エディタのCursorの開発元自身、シビアな用途で利用する際は注意するよう呼びかけています。

While we have several large organizations already trusting Cursor, please note that we are still in the journey of growing our product and improving our security posture. If you’re working in a highly sensitive environment, you should be careful when using Cursor (or any other AI tool).
(ref: https://www.cursor.com/ja/security)

エディタ内からAIに問い合わせなければ大丈夫とも言いきれません。AI連携エディタはバックグラウンドでもAIを利用しており、気付かないうちに情報が送信されうるためです。むしろ機密情報の書かれた設定ファイルを開くだけでもリスキーと考えるべきです。つまるところ、極めて厳しいセキュリティが必要とされる情報を取り扱っているなら、それらにアクセス自体できないようAI連携エディタを物理的あるいは論理的にシャットアウトするのが一番です。

og

AIは便利だが機密情報まで送信すべきでない

専用ユーザーを作ろう

Windows11の場合、AI連携エディタを利用して開発を行うための専用ユーザーを作成することで、外部に送信される可能性のある情報をしっかり管理できます。この専用ユーザーにはあらかじめ公開可能なプロジェクトのみを渡し、機密情報が保存されたディレクトリにアクセスできないようにしておきます。うっかりミスで機密情報をAI連携エディタに渡してしまう事態を

Powershellで実施する場合はこのようなコードになります。

# AI連携エディタ用ユーザーの作成
# 
# [Usage]
# 1. 管理者権限で PowerShell を開きます。
# 2. スクリプトを一時的に実行できるようにします。(e.g. `Set-ExecutionPolicy RemoteSigned -Scope Process`)
# 3. スクリプトを保存したディレクトリに移動し、実行します。 (e.g. `.\create-ai-user.ps1 -Username AIUser -Password pass_is_here`)

param (
    [Parameter(Mandatory = $true)]
    [string]$Username,

    [Parameter(Mandatory = $true)]
    [string]$Password
)

$SecurePassword = ConvertTo-SecureString $Password -AsPlainText -Force
New-LocalUser -Name $Username -Password $SecurePassword -FullName "$Username" -Description "AI editor user (developer)"
if (-not $Username) {
    Write-Error "Fail to create user: $Username"
    exit 1
}

Add-LocalGroupMember -Group "Users" -Member $Username

管理者ユーザーではなくローカルユーザーとして作成します。その上で機密情報を取り扱うディレクトリやファイルのアクセス権を拒否し、アクセス自体不可能にします。

開発環境

記事作成補助用のプロンプト

プロンプト

# 技術系ブログ記事のタイトルとdescription(概要文)を提案させるプロンプト
tweet_from_article:
  prompt: |
    添付ファイルで渡された内容を元に、SEOと読者理解の両面から最適なタイトルとdescription(概要文)を3セット作成し、YAML形式で返してください。語調は落ち着いていて読者に内容が伝わりやすいものにしてください。

    - titleは、読者が「この記事は何について書かれているか」「自分に関係があるか」がすぐわかるようにしてください
    - タイトルの長さは20〜45文字程度を目安にしてください。やや具体的な構文を用いてください(例:「〜する方法」「〜の作り方」「〜の手順」など)
    - descriptionは100〜160文字程度におさめ、記事の目的・扱う技術・学べる内容を端的に表してください
    - 誇張表現(例:「最強」「神」「絶対に見るべき」「衝撃の〜」など)や煽り文句(例:「衝撃」「最強」「絶対に見るべき」など)は使用しないでください
    - 曖昧な言い回しや過度な抽象語(例:「環境構築」「セキュリティ対策」など)には具体性を添えてください
  output_format: |
    - title: [タイトル案1]
      description: [概要文1]
    - title: [タイトル案2]
      description: [概要文2]
    - title: [タイトル案3]
      description: [概要文3]
  output_format: |
    - title: Windows11でAI連携エディタを安全に使うための専用ユーザー作成手順
      description: AI連携エディタからの外部送信リスクを最小化するために、Windows11で専用ローカルユーザーを作成し、機密ディレクトリのアクセス権を制限する手順を解説します
    - title: PowerShellでつくる、AI連携エディタ用の安全なユーザー環境
      description: APIキーや顧客情報など高機密データを誤送信しないために、公開用プロジェクト専用ユーザーを用意し、PowerShellで権限を分離する方法と注意点をまとめました
    - title: AI連携エディタの情報漏洩を防ぐ、権限分離の実践ガイド(Windows11)
      description: CursorなどAI連携ツールを安心して導入するためのセキュリティ方針、権限設定例、実行ログを示しながら、効率と安全を両立させる現実的な対策を紹介します

# X(Twitter)向けの技術記事の紹介投稿文を生成するプロンプト
tweet_from_article:
  prompt: |
    添付ファイルで渡された内容を元に、次の構成でX用の投稿文の元データを3点生成し、YAML形式で返してください。

    投稿文はX(Twitter)に適した口調・長さで書いてください。落ち着いた語調を用いてください。不安を煽るような疑問文・リスク強調表現(〜してませんか?、リスクです、危険性が〜など)は避けてください。
    Summaryでは、以下を意識して記述してください:
    - 情報の目的、工夫、改善ポイントなどに焦点をあてること
    - 専門用語(例:環境分離、アクセス制御、CI/CDなど)を適度に含めること
    - 「〜するには〇〇がカギ」「〜する工夫」「〜のための〇〇」といった穏やかな構文を使うこと
    - 必要に応じて絵文字を自然に1つ含めてもよい(例:🔐⚙️📌など)

    Profit部分では、記事を読むことで得られる知見・手法・導入メリットを具体的に記述してください。
  structure:
    - Summary: 導入・注意喚起・共感などのフックとなる短文
    - Profit: 読むことで読者が得られるメリット
  output_format: |
    - 
      summary: [Summary]
      profit: [Profit]
  output_example: |
    - 
      summary: IaCとCI/CDのメリデメをおさらい。
      profit: AWS CodePipelineやTerraformとの効果を最大限に引き出すポイントも。
    - 
      summary: IaCとCI/CDの要点まとめ。
      profit: AWS CodePipelineやTerraformの効果を引き出すには?
    - 
      summary: 必要なのはTerraformの導入だけではない。
      profit:  IaCとCI/CD導入の勘所。AWS CodePipelineやTerraformを使いこなす秘訣とは

Making