TL;DR
- これまで参加したイベントのまとめ。
- 学びから、「ただ聞いているだけでは何の意味もない」と思い、実際に業務にて実践した話。
- 客先常駐という制約もあり導入出来ないものも多々あったが、その中でも導入を推進したものを記録として残す。
はじめに
今まで個人学習を継続的に推進していきましたが、レベルの高いエンジニアの方や企業がどの様に業務を推進しているのかを知りたくなりました。
そこで、2025 年 11 月から本格的に connpass で開催しているイベントに参加することにしました。
当ブログのイベントをまとめたものは以下になります。
AWSとHugoを使った静的サイトのテックブログです
イベントに参加するごとにブログへまとめを進めてきましたが、 ただブログに書いているだけでは何の意味も無い と感じたため、実際に常駐先にどのような形で導入したのかをまとめていきたいと思います。
推進したものリスト
以下、これまで書いてきた記事から、実際に導入・推進してきたものになります。
客先のエンドユーザー様の意向や常駐先での導入が諸々の理由で実現不可能となったものもあり、実現不可能になったものは導入できませんでした。
どろんこ AI 話〜綺麗じゃない AI の苦労話〜 を視聴して【イベント感想】
TL;DR 「綺麗じゃない」実践知が山盛り。課題定義・責任境界・計測を先に決めることが成否を分けると再確認。 生成 AI は“使いどころ”の設計が命。UX 起点で仮説 → プロトタイプ → 学習ループを高速に回す文化が要。 モデル/外部 API への依存は前提。互換 …
2025 年 12 月時点での常駐先には Microsoft Copilot（以降、Copilot） が用意されておりました。
作業時にエラーや不明点がでてきた際に各々で Copilot を利用して問題解決していくのですが、各自での Copilot の使い方が統一されていないこともあり 出力された回答にばらつきが生じてしまいました。
そこで、以下の利用方法に絞って Copilot に対するテンプレートを作成することで問題解決に対する回答精度を向上させることを導入することにしました。
1. AWS 関連エラー/警告の解説・原因分析・解消法テンプレ
以下は AWS に関する問題です。
再現環境・ログ・条件を整理して説明して、「原因の可能性」「すぐ試せる切り分け手順」「根本原因対応」を返してください。
出力は Markdown 形式で構成してください。
---
### 1. 問題の概要
- サービス/リソース: <例: ECS Fargate サービス>
- リージョン: <例: ap-northeast-1>
- 権限/ロール: <IAM Role info>
- 発生タイミング: <Deploy/Update/Scale>
### 2. 入力した操作とレスポンス
- 実行したコマンド/操作:
<aws CLI or console 操作>
- 得られたエラーメッセージ:
<Error log snippet, up to 10 lines>
### 3. 現在までに試したこと
- <例: タスク定義コンテナ再ビルド, セキュリティグループ確認など>
---
**要求される出力**
1. **推定原因（根拠付き）**
2. **試すべき切り分け手順（ステップ）**
3. **最終的な解決手順例**
4. **関連ドキュメントや CLI 例**
2. コンテナデプロイ用シェル生成テンプレ
私は以下の AWS 環境でコンテナをデプロイしたいです。
指定した要件に応じた **bash シェルスクリプト（CLI）** を生成してください。
生成するシェルには必ずエラー処理・ログ出力・必要な前提条件チェックを含めてください。
---
## デプロイ要件
1. 対象サービス: <ECS>
2. クラスター/サービス名: <名前>
3. イメージリポジトリ: <ECR URI>
4. タスク定義/Pod spec の要点:
- CPU/Mem
- ポート
- Env vars
5. IAM Role / Policies: <Role 名>
## 必須要件
- 成功/失敗時の exit code を返す
- 実行ログを適切に CloudWatch Logs へ送る
- 既存タスクが存在する場合は確認と警告表示
---
**期待出力**
- 実行可能な `deploy.sh` コード
- 実行例（引数付き）
- 必要な前提条件チェック一覧
3. CI/CD（デプロイ時）エラー解析テンプレ
以下は CI/CD のビルド/デプロイエラーに関する情報です。
GitHub Actions などの YAML、ログ、失敗したステップ名を提示します。
原因の可能性と修正案を **可能な限りステップごとに整理して Markdown で返してください**。
---
### 1. 環境
- CI/CD ツール: <GitHub Actions / CodePipeline / Jenkins …>
- AWS リソース: <サービス名/リージョン>
### 2. 失敗ステップ
- ステップ名: <例: Build/Deploy>
- 関連 YAML/Workflow:
<該当部分の 20 ～ 40 行以内の抜粋>
### 3. エラーログ
<エラーのログ（最大 15 行）>
導入したことによる効果
- テンプレ化することにより、問題箇所のみを抽出できるので AI への問い合わせのハードルが下がった。
- テンプレ化することにより回答精度のばらつきが減った。
freee 技術の日 2025 参加メモ【イベント感想】
TL;DR 2025 年 11 月 30 日（日）開催の「freee 技術の日 2025」を視聴（インフラ/ SRE 関連セッションのみ）。 SLO 注釈 Service Level Objective。SLI に対する“目標値”。 …
役割分担
2025 年 12 月現在で参画している案件にて、インフラチームに在籍しておりました。 人数は TL 含む 7 名（実働メンバー 6 名）で、それぞれの役割りがフワッとしておりアプリチームからの問い合わせに対する対応も各々がバラバラで対応している関係で TL が管理することが難しいと感じておりました。 そこで、役割分担を以下のように推進することにしました。（私は AWS チームを担当）
- CI/CD チーム：
- Jenkins にてアプリのデプロイに関する部隊（2 名）
- AWS チーム：
- コンテナデプロイ後にエラーが出た際の分析や解消の対応（2 名）
- アプリごとの独自シェルの導入（1 名）
- アプリごとに導入したいシェルや内部の処理についてアプリチームからヒアリングし対応する
相談窓口の制定
チャットツールは Teams を利用していたのですが、以下のようなチャットルームしか存在しておりませんでした。
（以下のチャットルーム名は仮称）
- 内部用（参画プロジェクト全体用）
- インフラチーム
- アプリチーム
これまではインフラチームへ依頼があった際に内部用に一律で問い合わせがされていました。
内部用は多数使われていたので、問い合わせが埋もれていたり問い合わせ内容のフォーマットが決まっていなかったりなど、かなり煩雑になっていました。
そこで、 「インフラ依頼」 というチャットルームを作成し、以下のようなフォーマットを制定することにしました。
インフラ依頼用問い合わせフォーマット
# インフラ依頼フォーマット
## ① 問い合わせ種別（必須）
- 該当するものを【1 つ】選んで残してください
- アプリのデプロイ依頼
- デプロイ後、アプリに接続できない
- 環境変数 / Secrets Manager の確認・変更
- インフラ設定の確認（SG / IAM / ALB / ECS / RDS など）
- 障害・エラー調査
- その他（下に内容を記載）
---
## ② 問い合わせ内容（必須）
（「何が起きているか」「何をしてほしいか」を簡潔に）
例：
- ECS サービス xxx の最新デプロイ後から、
- ALB 経由でアプリにアクセスすると 502 が発生しています。
- インフラ側で以下の点を確認してほしいです。
- ALB Target Group のヘルスチェック状態
- タスク起動状況
---
## ③ 対象環境（必須）
- 環境名（dev / stg / prod）：
- AWS リージョン：
- サービス名 / リソース名：
---
## ④ アプリ担当者（必須）
- 氏名（Teams 表示名）：
- 所属チーム：
- 緊急時の連絡可否：可 / 不可
---
## ⑤ 発生日時・タイミング（任意だが推奨）
- 発生日時：YYYY/MM/DD HH:mm
- 発生のきっかけ（デプロイ / 設定変更 / 不明 など）：
---
## ⑥ エラー・ログ情報（任意）
（分かる範囲で OK）
- HTTP ステータス：
- エラーメッセージ：
- CloudWatch Logs のロググループ名：
---
## ⑦ 緊急度（必須）
- 高：本番影響あり / 業務停止
- 中：本番影響なしだが早めに対応したい
- 低：調査・相談レベル
---
## ⑧ 補足・参考情報（任意）
- 関連 PR / チケット URL：
- 過去に同様の事象があれば：
導入したことによる効果
- 役割分担
- 役割りを分けることにより、各個人のタスクに集中して取り組むことが出来た。
- インフラチームへ問い合わせる際に、担当を決めることにより属人化を防ぐことが出来た。
- 相談窓口の制定
- 問い合わせ内容をテンプレ化することにより、どれが問題なのかがわかりやすくなった。
- インフラ依頼用のチャットルームを分けることにより、チャット内容が煩雑にならなくなった。
まとめ
客先常駐という制約が多い環境の中で、出来る限りのことは実現できたのかなと思います。
また、イベントに参加したことをアウトプットすることが出来たこともいい経験になったと個人的には感じました。