SHIFT インフラサービスグループの水谷です。 久しぶりの Ansible に関する投稿になります。

はじめに # 先日、GitHub Actions ワークフローで background 機能が実装され、単一のワークフロー内でステップを並行で実行可能になったことが発表されました。 https://github.blog/changelog/2026-06-25-actions-steps-can-now-be-run-in-parallel/ これまでも、Strategy Matrix を使うと複数のランナーを使って並行処理させることはできましたが、今回の機能で、単一のランナーでの並行処理がサポートされたことになります。 公式ドキュメント には、バックエンドとフロントエンドのビルドを並行で実行するサンプルが掲載されています。 steps: - name: Build frontend id: build-frontend run: npm run build:frontend background: true - name: Build backend id: build-backend run: npm run build:backend background: true - name: Run linter while builds run run: npm run lint - name: Wait for both builds to finish wait: [build-frontend, build-backend] - name: Run tests run: npm test 並行実行を試す (background 版) # ステップ毎に background: true を指定する方法です。この属性を付与したステップは、実行開始後即座にフォアグラウンドに処理を戻します。 name: Background Hello World on: workflow_dispatch: jobs: hello-background: runs-on: ubuntu-latest steps: - name: Background hello 1 #1 id: hello1 run: | echo "hello1 start: $(date -u +%H:%M:%S)" sleep 4 echo "hello1 end: $(date -u +%H:%M:%S)" background: true - name: Background hello 2 #2 id: hello2 run: | echo "hello2 start: $(date -u +%H:%M:%S)" sleep 3 echo "hello2 end: $(date -u +%H:%M:%S)" background: true - name: Foreground step (runs while background steps are active) #3 run: | echo "foreground start: $(date -u +%H:%M:%S)" sleep 1 echo "foreground end: $(date -u +%H:%M:%S)" - name: Wait for background steps #4 wait: [hello1, hello2] - name: Done run: echo "Both background steps have completed." バックグラウンド実行するステップ。4秒間のスリープの開始と終了で時刻を表示します。 background: true を指定します。 バックグラウンド実行するステップ２個目。1個目と同様の処理です。スリープは3秒にしてます。 バックグラウンド実行しながら、フォアグラウンドで実行されるステップ。1秒間スリープします。 バックグラウンドの2つのステップを待ち受けるステップです。 wait でステップの ID を配列で指定するだけです。 実行結果です。 hello1 と hello2 が同一時刻に開始され、1秒違いで終了しています。 フォアグラウンドステップも2つのバックグラウンドステップと同時刻に開始されています。 wait ステップで2つのバックグラウンドステップの完了を待っています。 --> Information 上記のサンプルでは単純な sleep と echo をバックグラウンドで実行し、wait で待機しているだけですが、実際の CI/CD パイプラインでは「バックグラウンドで起動したサーバーやプロセスの結果を後から使いたい」というユースケースがよくあります。このようなケースでは、出力は一時ファイルに書き出しておき、wait後のステップでそれを読み込むといった工夫が必要になります。 並行実行を試す (parallel 版) # parallel キーワード配下にステップを並べるだけで並列化できます。parallel ブロックを抜けると完了するため、wait で待つ必要はありません。 name: Parallel Hello World on: workflow_dispatch: jobs: hello-parallel: runs-on: ubuntu-latest steps: - parallel: #1 - name: Parallel hello 1 run: | echo "parallel-1 start: $(date -u +%H:%M:%S)" sleep 4 echo "parallel-1 end: $(date -u +%H:%M:%S)" - name: Parallel hello 2 run: | echo "parallel-2 start: $(date -u +%H:%M:%S)" sleep 3 echo "parallel-2 end: $(date -u +%H:%M:%S)" - name: Parallel hello 3 run: | echo "parallel-3 start: $(date -u +%H:%M:%S)" sleep 2 echo "parallel-3 end: $(date -u +%H:%M:%S)" - name: Done after all parallel steps #2 run: | echo "done step start: $(date -u +%H:%M:%S)" echo "All parallel steps have completed." echo "done step end: $(date -u +%H:%M:%S)" parallel 配下に3つのステップを配置します。sleep は4秒、3秒、2秒とバリエーションを持たせています。 通常のステップです。parallel ステップ完了後に実行されます。 実行結果です。 hello1, hello2, hello3 が同時刻に開始されています。それぞれ指定通り、4秒、3秒、2秒実行にかかっています。 最後のステップは、parallel ステップ完了後の時刻から開始されていることがわかります。 クロスコンパイルで使ってみる # 応用として、すぐに思いつくのは、クロスコンパイルで複数プラットフォーム向けのバイナリ生成を並行で実行することです。例えば、Go 言語では Linux / macOS / Windows の向けのバイナリをクロスコンパイルできます。 - name: Build run: | GOOS=linux GOARCH=amd64 go build -o build/linux-amd64/sb2md main.go GOOS=linux GOARCH=arm64 go build -o build/linux-arm64/sb2md main.go GOOS=windows GOARCH=amd64 go build -o build/windows/sb2md.exe main.go GOOS=darwin GOARCH=amd64 go build -o build/macos/sb2md main.go GOOS=darwin GOARCH=arm64 go build -o build/macos_arm/sb2md main.go 並列化する以前のビルド結果です。5つのバイナリを生成するのに44秒かかっています。 並列化を適用しました。run で複数行書いてましたが、個別のステップに分けて、parallel 配下に置きました。 - parallel: - name: Build linux amd64 run: GOOS=linux GOARCH=amd64 go build -o build/linux-amd64/sb2md main.go - name: Build linux arm64 run: GOOS=linux GOARCH=arm64 go build -o build/linux-arm64/sb2md main.go - name: Build windows amd64 run: GOOS=windows GOARCH=amd64 go build -o build/windows/sb2md.exe main.go - name: Build darwin amd64 run: GOOS=darwin GOARCH=amd64 go build -o build/macos/sb2md main.go - name: Build darwin arm64 run: GOOS=darwin GOARCH=arm64 go build -o build/macos_arm/sb2md main.go トータルは40秒でした、Linux amd64 のビルドは3秒で終わってますが、他のプラットフォーム用のビルドはそれぞれで40秒かかっています。思ったより短縮されませんでした。考えられる原因としては、やはりランナーの CPU コア数でしょうか。 ランナー(ubuntu-latest)の vCPU が2コアであることから多重度が上がらなかった 5つのプロセスが2つのコアを奪い合ってコンテキストスイッチが大きかった ランナーのアーキテクチャ自体が Linux amd64 なので、ネイティブのバイナリ生成は瞬時に終わった CPU コアの多い Larger Runner にすればもっと短縮できそうですが、40秒が3秒程度に短縮されるだけなら、コストパフォーマンスはイマイチですね。今回のユースケースには合わない感じがします。 さいごに # 以上、GitHub Actions ワークフローでの並行ステップ実行を試してみました。 今回試したGoのクロスコンパイルのように、CPUヘビーで互いに独立したタスクであれば、これまで通りStrategy Matrixを使って別々のランナーを立ち上げた方が高速に処理できる可能性が高いです（課金は高くなりますが）。 一方で、今回の並行ステップ実行は公式ドキュメントのサンプルにあるような「バックエンドとフロントエンドのビルド」や「テスト実行と並行しての Lint 実行」など、単一ランナーの空きリソース（I/O待ちの時間など）を効率よく活用したい場面で輝く機能だと言えるのではないかと思います。

この度、Amazon Quick on Desktop が AWS アジアパシフィック (東京) リージョンでプレビュー利用可能になりました。2026年3月の東京リージョンローンチに続き、4月にプレビュー公開されたデスクトップアプリケーションも東京リージョンに対応しています。これにより、日本のお客様はデータを国内に保持しながら、デスクトップ上でよりパーソナルでプロアクティブな AI アシスタント体験を実現できます。 “Amazon Quick on Desktop は、本ブログ投稿時点では Preview であり、機能・仕様が変更される場合がございます。”  Amazon Quick on Desktop とは Amazon Quick on Desktop は、Amazon Quick をブラウザの枠を超えてお使いのコンピュータにネイティブに展開するデスクトップアプリケーション (macOS / Windows 対応) です。ローカルファイルへの直接アクセス、OS レベルのプロアクティブ通知、バックグラウンドエージェント、ブラウザ自動化、パーソナルナレッジグラフ といった機能を備えています。 Quick on Desktop でできること ローカルファイルと直接連携 : チャットエージェントにアップロード不要で、許可したフォルダ内のファイルを読み書き・検索・インデックス化。ドキュメント作成やデータ分析もローカルファイルを直接参照して実行できます。 バックグラウンドエージェント : スケジュールに基づいて自動実行されるエージェントが、チャネル監視・メールトリアージ・ミーティング要約・インシデント追跡などを代行します。 プロアクティブ通知とアクティビティフィード : 接続サービスを監視し、重要な情報をデスクトップに通知。アクティビティフィードで優先度順に一覧表示します。 ブラウザ自動化 : Chrome を起動・制御し、Web フォーム入力、スクリーンショット取得、データ抽出、Web アプリとの連携を Quick に委任できます。 パーソナルナレッジグラフ : Slack メッセージ、メール、カレンダーなどの連携サービスおよびローカルファイルからエンティティと関係性を自動抽出し、あなた専用のナレッジグラフを構築。Quick の回答がよりユーザーに沿ったものとなります。 MCP サーバー接続 : Model Context Protocol (MCP) で外部ツールやコーディングエージェントと連携し、Quick の能力を拡張できます。 ドキュメント生成 : Word、Excel、PowerPoint などをチャットから直接生成できます。 ローカルファースト・アーキテクチャ Quick on Desktop は ローカルファースト・アーキテクチャ を採用しています。AI バックエンドはお手元のマシンで実行され、ファイルもローカルに留まります。ネットワーク通信は API Gateway 経由の AI モデル呼び出し と、 接続済みサービス (Slack, Outlook, Gmail 等) への通信 のみです。この設計により、プライバシーを保護しつつ Quick の機能を活用できます。 東京リージョン対応のメリット 1. 国内データレジデンシー データが日本国内の AWS インフラストラクチャに留まるため、個人情報保護法 (APPI) やお客様組織の内部ガバナンス要件を満たしやすくなります。 2. JP-CRIS による国内推論 JP-CRIS (Japan Cross-Region Inference) により、東京リージョンからの推論リクエストは 東京 (ap-northeast-1) と 大阪 (ap-northeast-3) の AWS リージョン内のみでルーティングされます。推論が日本国外で実行されることはありません。 3. 低レイテンシー 日本国内ユーザーのネットワークレイテンシーが改善され、AI 応答やダッシュボード表示、ワークフローの応答などのパフォーマンスが向上します。 最新アップデート Amazon Quick on Desktop は継続的にアップデートされています。 AWS Summit New York で発表された最新機能を含め、注目のアップデートをご紹介します。 Autonomous Agent — あなたの代わりに動き続ける AI Quick に Autonomous Agent（自律型エージェント） が追加されました。自然言語で目的を記述するだけで、バックグラウンドで継続的にタスクを実行するエージェントを作成できます（ 公式ブログ ）。 特徴: ノーコード作成 : 自然言語で目的を伝えるだけで作成可能。プリセットライブラリからの選択にも対応 柔軟な自律レベル : ステップバイステップの指示から、ゴールだけを与えてエージェントに判断させるモードまで選択可能 常時稼働 : ミーティング中や退席中でもバックグラウンドで動作し続ける ガードレール制御 : エージェントごとにガードレールを設定し、動作を制御 学習と改善 : やり取りや修正を通じてエージェントは時間とともに賢くなる Activity Feed — 1日の始まりをトリアージから解放 Quick Desktop の Activity Feed が大幅に強化されました。メール、メッセージング、カレンダー、タスクを 1つの優先度付きビュー に集約し、AI がトリアージを代行します。 特徴: 統合ビュー : メール、メッセージング、カレンダー、タスクを横断的に一元表示 AI によるプライオリティ付け : どのメッセージに素早く返信するか、どのスレッドをスキップするか、どのトピックが重要か判断 サマリーカード : 複数の関連メッセージを返信ドラフト付きの1枚のカードに要約 その場でアクション : 返信、転送、承認、委任をフィードから直接実行（アプリ切替不要） Skills & Agents カタログ 組み込みの スキル・エージェント・コネクタのカタログ がローンチされ、数クリックで導入・共有が可能に。営業、財務、マーケティング向けの 30 以上の準備済みスキルが用意されています。 Quick on Desktop の始め方 Amazon Quick on Desktop を始めるのは簡単です。 アカウント作成 : quick.aws.com で Free または Plus アカウントにサインアップします（AWS アカウント不要、メールアドレスのみで登録可能） アプリダウンロード : ダウンロードページ から macOS または Windows 版のデスクトップアプリケーションをインストールします フォルダ許可 : Quick にアクセスさせたいローカルフォルダを設定します サービス接続 : Slack、Outlook、Gmail 等のビジネスアプリケーションを接続します ナレッジグラフ構築開始 : 使い続けるほどコンテキストが蓄積され、よりパーソナライズされた体験になります エンタープライズ (Professional / Enterprise) アカウントのお客様は、IAM Identity Center による SSO 連携や、管理者によるエンタープライズデプロイも可能です。 エンタープライズセキュリティとガバナンス Quick on Desktop は、ローカルファーストの設計思想に基づきセキュリティとデータプライバシーを確保しています。 ファイルはローカルに留まる : Quick on Desktop はローカルファースト・アーキテクチャを採用しており、ファイルがクラウドにアップロードされることはありません。ユーザーが許可したフォルダのみアクセスし、いつでもアクセスを取り消せます。 ネットワーク通信は最小限 : ネットワーク通信は API Gateway 経由の AI モデル呼び出しと接続済みサービス (Slack, Outlook 等) への通信のみ。データがモデルのトレーニングに使用されることはありません。 エージェントのガードレール : Autonomous Agent にはエージェントごとに自律範囲を設定でき、意図しないアクションを防止します。 フォルダ単位のアクセス制御 : ローカルファイルへのアクセスはフォルダ単位で許可/取り消しが可能。キーワード検索、セマンティック検索、ナレッジグラフ抽出もフォルダ単位で制御できます。 東京リージョンでの JP-CRIS : AI モデルへの推論リクエストは東京・大阪リージョン内に閉じてルーティングされるため、データが日本国外に出ることはありません。 まとめ Amazon Quick on Desktop の東京リージョン対応により、日本のお客様はデスクトップ上でも Quick の AI アシスタントを活用しつつ、データ保全と低レイテンシーの恩恵を受けられるようになりました。ローカルファイルとの深い統合、プロアクティブな通知、パーソナルナレッジグラフ、そしてバックグラウンドエージェントによる自動化が、日々の業務を根本から変革します。 ぜひ Amazon Quick on Desktop をお試しください。