クラウドインフラは混沌としがちです。「EC2インスタンスが応答しない」や「CPU使用率が高い」といったアラートが発報すると、初動のトリアージはしばしば考古学的発掘のように感じられます。アナリストはチケットシステムを離れ、AWSコンソールに認証してログインし（MFAプロンプトが出てきて）、該当するリソースIDを探し回り、事実を確認するための正しいCLI構文を思い出さなければなりません。
このコンテキスト切り替えの負担は大きいものです。平均解決時間（MTTR）を延ばし、問題を修正するよりもデータ収集に時間を費やすアナリストを疲弊させます。
本記事では、事前構築されたTinesワークフロー「エージェントを使用してCLIデータでAWSの問題を調査する」を取り上げ、CLIをケースに直接持ち込むことで、こうした手作業のデータ収集を排除する方法を解説します。
問題：インシデント対応における「コンテキストギャップ」
多くの組織では、作業の追跡場所（Jira、ServiceNow）とデータの所在（AWS、Azure、社内ログ）の間に断絶があります。
「単純」な調査でも、しばしば次のような作業が必要になります：
- アクセスの摩擦：複数のコンソールにログインし、ロールを引き受ける。
- 構文の苦闘：答えを取得するだけでよいのに、情報を調べるための正しいCLI構文やフラグを突き止めることに時間を浪費する。
- セキュリティリスク：ステータス確認のためだけに、アナリストへ本番環境への広範な読み取り権限を付与してしまう。
このような手作業プロセスはスケールの敵です。最近の Tinesのケーススタディで述べられているように、大手クラウドファンディング・プラットフォームでは、手作業のスプレッドシートからオーケストレーションへ移行することで、わずか90日で未パッチの脆弱性が83%減少しました。
教訓は？「その背後にある雑務ではなく、セキュリティ作業に集中すること」です。
手作業でITインフラを運用することの隠れたコスト
最新のIT運用チームが、オーケストレーションを活用してキャパシティを管理し、信頼性を向上させ、燃え尽きることなくインフラをスケールさせる方法を学びましょう。
この実践的ガイドでは、すでにお使いのツールを用いて、手作業のワークフローを予測可能で自動化された運用に置き換える方法を紹介します。
解決策：エージェントによるCLI実行の自動化
「CLIデータでAWSの問題を調査する」ワークフローは、チケットとクラウド環境の間のギャップを埋めます。Tinesエージェント（安全で軽量なランナーで、セキュアな認証情報を使ってAWSへコマンドを送信可能）を利用し、インテリジェントなワークフロー内でCLIコマンドを安全に実行して、その結果をアナリストへ返します。
アナリストがCLIへ行くのではなく、CLIがアナリストのもとへやって来ます。
以下は、このワークフローがどのように動作するかの概要です：
1. トリガー – AWSリソースに関する新しいケースまたはチケットが作成されると、ワークフローが開始します。これはCloudWatchアラームによって自動的にトリガーされる場合もあれば、アナリストが異常に気づいて手動で起票する場合もあります。
2. エージェントによる仲介 – Tinesはクラウドへ直接、過剰な権限でアクセスする必要がありません。代わりに、AWSに対して指定された読み取り専用アクセスで動作するTinesエージェントへ指示します。これにより、クラウドの認証情報はローカルに留まり、安全に保たれます。
3. 動的なコマンド生成 – ワークフローは硬直した事前定義スクリプトに依存しません。代わりに「魔法」は、チケットのコンテキストに基づいて必要なCLIコマンドをゼロから組み立てるエージェントの能力にあります。S3バケットポリシーを確認したい場合でも、EC2インスタンスのセキュリティグループをチェックしたい場合でも、エージェントは適切な構文をインテリジェントに形成して実行し、静的な自動化では得られない柔軟性を提供します。
4. AIによる整形とエンリッチメント – 生のCLI出力（しばしば密度の高いJSON）は、人間が素早く解析するには困難です。ワークフローはTinesの変換機能（または任意のAIステップ）を使ってこのデータを解析し、見やすい要約や表に整形します。
5. ケース更新 – 整形された調査結果は、Tines CaseまたはITSMツールに直接追記されます。アナリストはチケットを開くだけで、インスタンスの現在の状態、セキュリティグループ、パブリックIPを即座に確認できます。ログインは不要です。
メリット
このワークフローを実装することで、インシデントのライフサイクル全体にわたって効率が向上します：
- ゼロタッチのコンテキスト： アナリストは、必要なデータがすでに目の前にある状態で調査を開始できます。「収集フェーズ」はなく、「解決フェーズ」だけになります。
- セキュアなアクセス： すべてのジュニアアナリストにAWSコンソールの読み取り権限を付与する必要はありません。Tinesエージェントが権限を扱い、特定の承認済みコマンドに対する安全なプロキシとして機能します。
- 標準化されたドキュメント： すべての調査に、まったく同じデータスナップショットが添付されます。これにより完璧な監査証跡が作られ、TinesのCasesが自動的に記録します。
- 協調的な解決： データをTines Casesに取り込むことで、チームは「新規または未知」の事象についてリアルタイムにコメント、タグ付け、共同作業ができます。データがターミナルウィンドウに閉じ込められているときに起きがちなサイロ化したコミュニケーションを防げます。
構築方法
このワークフローは、インテリジェントワークフローの取り組みを素早く始めるためのテンプレートとして利用できます。
ステップ1：ストーリーをインポート Tines Libraryにアクセスし、 エージェントを使用してCLIデータでAWSの問題を調査するを検索します。「Import」をクリックしてテナントに追加します。
ステップ2：AWS認証情報を接続 エージェントが環境とやり取りできるようにするため、セキュアなAWS認証情報（IAMロールやアクセスキーなど）をTinesテナント内で直接接続します。複雑なインフラのデプロイや外部ランナーは不要です。
ステップ3：推奨コマンドを修正 テンプレートにはエージェントの指針となる例示コマンドのリストが含まれていますが、使用できるのはそれだけではありません。このリストを編集してエージェントの挙動を誘導し、チームで最も多いチケットに基づいて、より頻繁に使ってほしいコマンドを指定できます。
ステップ4：ケース形式を確認 ワークフローはすでにTines Casesへ調査結果を送るように事前配線されているため、手動での接続は不要です。ただし、アナリストに適したものになっているか、Caseのレイアウトは確認してください。フィールドの順序やAI要約の表示方法を調整し、最重要データが一目で分かるようにしたい場合があります。
ステップ5：テストして定義 ダミーチケットでワークフローを実行します。エージェントがコマンドを実行し、出力がCaseビューで正しく整形されていることを確認します。
結論
疲弊したSOCと効率的なSOCの違いは、しばしば「雑務」にあります。アナリストがアラートのたびに手動でデータを取りに行かなければならないと、ノイズに溺れてしまいます。
TinesとTinesエージェントでこれらの定型チェックをオーケストレーションすることで、状況は一変します。必要なコンテキストを即座にチームへ提供し、組織を実際に守る高付加価値な意思決定に集中できるようになります。
クラウドファンディングのテック企業が発見したように、インテリジェントワークフローは単に時間を節約するだけではありません。適切に実装されれば、セキュリティ態勢そのものを根本から変えます。
Tines Casesが調査データをどのように一元化できるかをより深く知りたい方は、この製品スポットライトをご覧ください： Tines Cases | 製品スポットライト。この動画では、Casesインターフェースがデータを統合する様子を示しており、本ワークフローが生成する自動化されたAWSインサイトの最適な集約先となることが分かります。
