エンジニアの定例作業をn8nで自動化 ー AWS ECSで実現するセキュア基盤構築と運用
アドウェイズグループ / 石井智也
メンバー / フルスタックエンジニア・プロダクトエンジニア / 従業員規模: 1,001〜5,000名 / エンジニア組織: 101名〜300名
| 利用プラン | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|---|
Community Edition(セルフホスト) | 10名以下 | 2025年10月 | B to B |
| 利用プラン | Community Edition(セルフホスト) |
|---|---|
| ツールの利用規模 | 10名以下 |
| ツールの利用開始時期 | 2025年10月 |
| 事業形態 | B to B |
アーキテクチャ

アーキテクチャの意図・工夫
セキュリティ要件
プライベートサブネット内にECSコンテナを配置し、社内IPアドレスからのアクセスのみに制限しています。コンテナをパブリックに露出せずに極めてセキュアな運用を実現しています。
ECS Fargateの採用理由
EC2と比較しコンテナのリソースを柔軟に変更できる点により採用しています。
n8nの要件としてはCPUよりもメモリを確保することが重要であるため0.5vCPU, 2GBメモリのコンテナで運用しています。
また、n8nが公式にDockerイメージを配布しているため、そのイメージをもとにaws-cliを導入したベースイメージをECRにアップロードするなど、最低限のカスタマイズで柔軟に運用できる点もECS採用理由の一つです。
ログ通知について
CPUへの負荷が高いワークフローをいくつか運用しており、全てが同一コンテナで稼働するため、ワークフローの実行時に高負荷状態が続きます。
その結果、管理画面へのアクセスが遅くなる事象が発生しました。
そのため、CPUとメモリの使用率を監視し常時死活監視を行っています。
全リソースはTerraformで管理しており、再現性の高いインフラ構築と変更管理を実現しています。
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
定型的な運用作業が多く、新機能開発等の業務に携わる時間が減ってしまうという課題がありました。具体的には以下のような作業が該当します。
- AWSなどからメールで届く各種リソースのアップデート告知を、タスク管理ツールに手動で起票する作業(1回あたり5〜10分)
- スプリントレビューに向けて、各個人の担当タスクを逐一確認し、社内ドキュメントへ貼り付ける作業(週で約15分)
- サービスへのアクセス履歴をS3やCloudWatchからダウンロードし、棚卸し管理用のファイルストレージにアップロードする作業(月初に約1時間)
これらひとつひとつの作業は工数が大きくないものの、積み重なることで本来着手したいタスクに遅れが生じてしまうという懸念がありました。
どのような状態を目指していたか
「定例作業の5割削減」をOKRとして策定し、さまざまな自動化ツールやAI Agentの導入・検証を実施することで、エンジニアが本質的な価値創造(新機能開発や品質改善)に集中できる環境を目指していました。
比較検討したサービス
- IFTTT
- Zapier
- n8n Cloud
- Dify
比較した軸
- ワークフローの柔軟性: 複雑な分岐等があるようなタスクでも実現が難しくないか
- コストの予測可能性: 実行数に応じた従量課金ではなく、定額で運用できるか
- AWS環境との統合性: 他AWSアカウントのリソースにアクセスできるか
選定理由
ワークフローの柔軟性
IFTTTのような決まった線形的な流れではなく、複雑な条件分岐を簡単に実現できる点が魅力的でした。
また、Zapier・Difyとの異なる点としてはコンテナ上でのシェルスクリプトの実行やJSを使った複雑なデータ成形ができる点も良く、エンジニア目線でやりたいことに対する制約を感じるといったことがなかった点も評価ポイントでした。
長期的なコストメリット
Zapierは実行数増加に伴い$299〜$599のプランへの移行が必要になりますが、n8nセルフホストでは実行数に関わらず定額(月額約$100)で運用できます。
AWS環境との統合性
n8nのクラウド版でもアクセスキー経由でAWSリソースへのアクセスが実現できます。
ただし、全てのAWSサービスに対応しているわけではなく、シェルスクリプトの実行はクラウド版では機能として提供していません。
そのため、AWS上のログ取得をしたいといった要件はセルフホスト環境で対応しており、他アカウントへのアクセスはSTSによる一時認証情報の取得で実現しています。副次的なメリットとして、キーローテーションの運用を意識せずに他アカウントへのアクセスを実現できています。
総じて、機能的な柔軟性と他環境へのアクセスの容易性が大きな決め手となりました。
導入の成果
改善したかった課題はどれくらい解決されたか
OKRとして掲げた「定例作業の5割削減」に対し、チーム全体で月あたり約4時間の工数削減を実現しました。
定例業務自体は月に15時間ほどであったため割合で言うと3割弱と指標としては未達となっていますが、作業内容の見直しなどの副次的な効果により数値に表れていない部分での改善も行えました。
引き続き、定例業務に関してはn8nを利活用していくことをエンジニアチームとしても決定しており、更なる改善を見込んでいます。
どのような成果が得られたか
- 削減された時間を新機能開発や品質改善といった本来注力すべきタスクに充てられるようになった
- メール見落としによる対応遅れのリスクが低減した
- 他部署からn8nの導入を行いたいといった声が上がっており、業務効率化の社内への波及が進んだ
導入に向けた社内への説明
上長・チームへの説明
コスト面
セルフホストとしてはやや高い料金ですが、従量課金と比較して今後実行回数が増えた場合でも変わらず定額で運用できること、さらに今後Dify等の他ツールを同一インフラに追加料金を抑えて展開できる拡張性を説明しました。
運用面
社内の別チームでの導入事例があり、どういった業務効率化ができるのかを導入前段階にヒアリングを実施することで、チームメンバーに対してどういったことに活用できるのかを実際の事例を用いて説明しました。
活用方法
メール内容を元にしたタスクの起票
メンテナンス通知やアップデート告知がメールで届くと、AI Agentが内容を分析して優先度を判定し、対応を要するものはタスク管理ツールに自動起票します。これにより、メール確認→内容理解→起票という一連の手動作業が不要になっています。
スプリントレビューでの活用
スプリント終了日の前日にスケジュールトリガーが発火し、タスク管理ツールのAPIから各メンバーの担当タスクを自動取得。テンプレートに沿って整形し、API経由で社内Wikiに自動で転記します。レビュー準備の時間を振り返りなど本質的な活動に充てられるようになりました。
監査対応でのログ取得の活用
セキュリティ監査用に、AWSの複数アカウントからS3・CloudWatch LogsのアクセスログをIAMロール経由で取得し、所定のフォーマットに変換した上で社内ファイルストレージの監査フォルダに自動アップロードしています。
よく使う機能
AI Agentノード
最も活用している機能です。LLMにプロンプトを渡し、AIからの応答をワークフローの出力として活用できます。
n8nではこれを1ノードとして提供しているため、複数のAI Agentを連結させたマルチエージェントシステムを視覚的に構築できます。例えば「メール内容の優先度を判断するAgent」→「タスク内容を要約するAgent」→「タスク管理ツールに起票するノード」といった流れをGUI上で直感的に組むことができます。
Execute Commandノード
n8nコンテナ内でシェルコマンドを直接実行できる機能です。
カスタムDockerイメージにAWS CLIをインストールしているため、このノード経由でaws s3 cpやaws sts assume-roleといったコマンドを実行し、AWSリソースとの連携を実現しています。
スケジュールトリガー
Cron式で定期実行を設定できるトリガーノードです。
スプリントレビュー資料の自動生成やアクセスログのアップロードなど、定期的なワークフローの起点として多用しています。
各種インテグレーション
n8nが標準で提供するインテグレーションノードにより、各SaaSとの認証・API呼び出しをノーコードで行えます。
ツールの良い点
- AI Agentノードにより、マルチエージェントシステムの設計・デバッグがGUI上で視覚的に行え、全体像を把握しやすい
- Dockerイメージが公式提供されており、カスタマイズしてECS等にデプロイしやすい
- 実行数に関わらず定額のため、コストの予測がしやすい
ツールの課題点
- セルフホスト環境のインフラ構築・運用に一定のAWSやTerraformの知識が必要
- NAT Gateway等のインフラ費用を含めると月額約$100と、セルフホスト事例としてはやや高コスト
- 公式Dockerイメージに含まれないツール(AWS CLI等)を使う場合、カスタムイメージの作成・管理が必要
ツールを検討されている方へ
n8nの導入を検討される場合、まずは「何を自動化するか」の見極めが最も重要です。n8n自体は技術的なハードルが低く、ワークフローの構築はGUIで直感的に行えますが、自動化対象の選定を誤ると投資対効果が見合わなくなります。
まずは1つの定型作業を自動化し、その効果を定量的に測定することをおすすめします。例えば、毎週発生している手動作業の工数を計測し、自動化後にどれだけ削減できたかを数値で示すことで、チームや上長への説明もしやすくなります。
セルフホストを選択する場合、初期構築にTerraformやECSの知識が必要ですが、一度構築してしまえば運用負荷は低く、今後他のセルフホスト型ツールを追加する際にもインフラを流用できるため、長期的な投資としては十分に価値があります。
今後の展望
CI/CDパイプラインの失敗通知・AIによるエラーログ要約、定期的なAWSコスト分析レポートの自動生成、新メンバーのオンボーディング自動化など、新規ワークフローの開発を計画しています。 加えて、RAG(Retrieval-Augmented Generation)を活用した社内ドキュメント検索の統合や、ワークフロー実行結果のフィードバックループによるAI Agentの継続的改善にも取り組む予定です。
ワークフロー実行数の増加に伴い、ECS ServiceのAuto Scaling設定やn8n公式が推奨するQueue Mode(Redis利用)の導入を検討しています。平日の業務時間帯は2タスクに増やし、夜間・休日は1タスクに縮小するといったスケジュールベースのスケーリングも視野に入れています。
アドウェイズグループ / 石井智也
メンバー / フルスタックエンジニア・プロダクトエンジニア / 従業員規模: 1,001〜5,000名 / エンジニア組織: 101名〜300名
よく見られているレビュー
アドウェイズグループ / 石井智也
メンバー / フルスタックエンジニア・プロダクトエンジニア / 従業員規模: 1,001〜5,000名 / エンジニア組織: 101名〜300名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法


