2026-03-09

【GitHub Copilot CLI】session-stateを分析してSkillsを抽出してみる

AI GitHub Copilot Skills

コード規約やワークフロー、ガイドのようなものをSkillsとして作成しているチーム（人）は既に多いと思いますが、それでもうまくいかないことも少なくはないと思います。これにはSKILL.mdが冗長すぎるとか、そもそも内容が古いなど考えられる原因は多岐に渡ります。

これらの原因を特定するための一つのアプローチとして、過去のCopilotとのセッションログを詳細に分析し、実装済みSkillsの改善と新規抽出に取り組んでみた、という話をさせていただきます。

セッションログの全体像

GitHub Copilot CLIとのやりとりは、基本~/.copilot/に保存されています。

公式ドキュメント：

docs.github.com

.copilot/のディレクトリ構成はこちら。

~/.copilot/
├── config.json   # ユーザー設定
├── mcp-config.json   # MCP サーバー設定
├── command-history-state.json
├── session-state/   # セッションログ本体（メイン）
├── history-session-state/   # 過去セッションのアーカイブ
├── logs/   # セッションログファイル
├── ide/   # IDE 連携情報
├── marketplace-cache/   # Copilot Marketplace のキャッシュ
└── pkg/   # インストール済みパッケージ

session-state/を覗いてみると、UUIDのディレクトリ並んでおり、私の環境では200個以上ありました。これが全部過去のセッション（= Copilotとの会話履歴）になっています。

config.json — 意外と多い情報量

// 079r67fe-e011-1a12-w26s-3efw82re24y8
{
  "last_logged_in_user": { "host": "https://github.com", "login": "your-name" },
  "theme": "auto",
  "model": "claude-sonnet-4.6",
  "reasoning_effort": "high",
  "trusted_folders": [
    "/Users/user.name/repository-name",
    "/Users/user.name/copilot-session-insight",
    ...
  ]
}

ログインユーザー、テーマ、デフォルトモデル、そしてtrusted_folders。どのプロジェクトを信頼フォルダとして登録しているかが一覧で分かります。自分の作業プロジェクトの遍歴を振り返れますね。

session-state/ の構造

各セッションディレクトリには以下のファイルが入っています。

~/.copilot/session-state/{sessionId}/
├── events.jsonl   # 1行1イベントのJSONL（全行動の記録）
├── workspace.yaml   # ワークスペース情報
├── vscode.metadata.json   # VS Codeメタデータ
├── session.db
├── checkpoints/   # チェックポイント（作業の節目）
│   ├── index.md
│   ├── 001-{title}.md
│   └── 002-{title}.md
└── files/   # セッション成果物（plan.md、調査レポート等）
├── rewind-snapshots/   # 巻き戻し機能
│   ├── index.json   # スナップショットのメタデータ一覧
│   ├── backups/   # バックアップの本体
│      └── <contentHash>-<timestamp>
├── research/

ちなみに、全207セッションのうち、events.jsonlがあるのは71個、checkpoints/があるのは122個でした（セッションの性質によって異なる）。

workspace.yaml — セッションのメタデータ

id: 079r67fe-e011-1a12-w26s-3efw82re24y8
cwd: /Users/user.name/repository-name
git_root: /Users/user.name/repository-name
repository: organization/repository-name
branch: feature/#2424-post-api-get-composite-part2
summary: Add Composite API Support
created_at: 2026-02-17T06:44:55.081Z
updated_at: 2026-02-18T01:36:23.085Z

どのリポジトリの、どのブランチで、何をしていたかが記載されています。summaryフィールドにはGitHub Copilotが自動生成したセッション要約が入っています。セッション一覧を眺めるだけで、過去の作業履歴を大まかに把握できます。

checkpoints/ — 作業の節目

/compactコマンドを実行するか長いセッションではチェックポイントが作られます。つまり、チェックポイント時点でのセッションコンテキストが圧縮されて保存されるわけですね。ちなみに、/compactを必ずしも手動でトリガーする必要はなく、セッションの長さや内容によって自動的に作成されることもあるようです。

docs.github.com

圧縮を手動でトリガーする必要がある場合は、/compactを使用します。これは、システムが自動的に処理するため、ほとんど必要ありません。チェックポイントは、セッションコンテキストが圧縮されるときに作成され、Copilotが作成した概要コンテキストを表示できます。

index.mdにはチェックポイントの一覧が、001-{title}.mdには各チェックポイントの内容が入っています。

| # | Title | File |
|---|-------|------|
| 1 | BigQuery統合パターン 学習・ナレッジ作成 | 001-bigquery.md |
| 2 | BigQuery Skills/Agents フォーマット変換 | 002-bigquery-skills-agents.md |

ディレクトリ構成

checkpoints/
├── index.md  # チェックポイント一覧
├── 001-composite-api-get-query-refact.md
├── 002-composite-api-skill-and-list-r.md
└── 003-composite-get-refactor-doc-syn.md

files/ — セッション成果物の保存先

plan.mdや調査レポートなど、セッション中に生成したファイルが格納されます。こんなものまで残っていました。

files/composite-api-investigation-report.md

Copilotに「調査結果をファイルに保存して」と頼んだときに作られたものでした。ただのチャット履歴ではなく、成果物まで丸ごと保存されていることもあります。

events.jsonl — 行動のフルログ

本命はここです。events.jsonlを開くと、1行1イベントのJSONLが並んでいます。

session.start       2026-02-17T06:44:55
user.message        2026-02-17T06:45:51
assistant.turn_start
assistant.message
tool.execution_start
tool.execution_complete
skill.invoked       ←Skillが呼ばれた記録
assistant.turn_end
subagent.started    ← サブエージェントが起動した記録
...

主要なイベント型の一覧：

type	内容
`session.start`	セッション開始。`branch`, `repository`, `copilotVersion`など
`user.message`	ユーザーのプロンプト本文 + 添付ファイル一覧
`assistant.message`	AI の応答
`tool.execution_start`	ツール呼び出し（Read, Edit, Bash, Glob など）
`tool.execution_complete`	ツール実行結果（`success: true/false`）
`skill.invoked`	Skillが呼ばれたとき。Skill名とパスと内容が記録される
`subagent.started`	サブエージェントの起動

skill.invokedイベントが特に面白くて、「どのセッションで、どのSkillが呼ばれたか」や「Skillの内容自体」が全部記録されています。

{
  "type": "skill.invoked",
  "data": {
    "name": "composite-api-query-skills",
    "path": "/Users/user.name/repository-name/.github/skills/composite-api-query-skills/SKILL.md",
    "content": "---\nname: composite-api-query-skills\ndescription: Composite APIを使った..."
  }
}

セッションログから読み取れること

実際にログを集計してみると、自分の行動パターンが数字で見えてきます。

リポジトリ別セッション数（workspace.yamlのrepositoryを集計）:

// プライベートリポジトリなのでディレクトリ名は仮にしています
72回 [Orgs]/hoge-project
38回 [Orgs]/huga-project
...

さらにevents.jsonlを分析すると：

どのツールをよく呼ぶか（Read? Edit? Bash?）
ツールの成功率（tool.execution_completeのsuccessから）
何時に作業が集中するか（timestampの時間帯分布）
どのSkillがよく呼ばれるか（skill.invokedの集計）
どんな意図の依頼が多いか（user.messageの内容）

これら全部をセッションログから読み取とることができます。つまりCommit履歴など細かく振り返らなくても自分の開発スタイルを丸ごと分析可能ということですね。

Skillsへの抽出

ログを眺めていてふと思ったのが、「繰り返し出てくる依頼パターンはSkill化できるのでは？」ということです。

user.messageを見ると、こんな依頼が何度も出てきます：

「このファイルにテストを書いて」
「ユニットテスト追加して」
「spec を作成して」

表現は違うけど意図どれも同じですよね。このパターンを検出できれば、「テスト生成」というSkillを作るべきだと分かります。

さらにtool.execution_startのシーケンスを見ると、こんなパターンが繰り返されています：

Read → Edit → Bash(test) → Bash(lint)

これも「編集→テスト→lint」という定番ワークフローで、Skill化の候補です。

skill.invokedが記録されていることも重要で、ここから「このSkillは既に活用されている」という事実もログから読み取れます。活用されていない繰り返しパターンを見つけて新規Skillを作り、既存Skillの呼ばれ方を見てチューニングする——ログがSkill設計のフィードバックループになります。

実際にやってみた

「じゃあ実装しよう」と思ったとき、最初に考えたのはTypeScript + Copilot SDKでパイプラインを書くことでした。が、これ自体を、Skillsとして書けばいいんじゃないか？と思い直しました。

SDKでやろうとしていたのは「セッションログを読んで、パターンを見つけて、Skill候補を出す」ことです。ですがそれ自体、Copilot自身がファイルを読めるし構造化データの分析もできるし、パターン検出もできます。わざわざコードを書かなくても、分析の観点をSKILL.mdに書いておけば、Copilotが直接ログを読んで分析してくれるはずです。

実際にcopilot-skill-extractというSkillを作って実践してみました。以下は一部抜粋ですが、SKILL.mdの内容はこんな感じです。

---
name: copilot-skill-extract
description: 'セッションログから繰り返しパターンを見つけてSkill化すべき候補を提案する'
allowed-tools: Read, Glob, Grep, Bash
---

GitHub Copilotのセッションログを分析し、繰り返されているパターンを検出してSkill化（自動化）すべき候補を提案する。

### データの場所と構造

セッションログは`~/.copilot/session-state/`に格納されている。

## 分析手順

1. ~/.copilot/session-state/ から直近30日のセッションを読み取る
2. 以下の5レイヤーで繰り返しパターンを検出する:
   - Layer 1: Intent Patterns — プロンプトを意味でグループ化
   - Layer 2: Prompt Templates — 構造が同じで変数が違うパターン
   - Layer 3: Domain Patterns — 同じドメイン知識が繰り返し必要なパターン
   - Layer 4: Workflow Patterns — ツールチェーンの繰り返し
   - Layer 5: Cross-Branch Promotion — 複数ブランチで出現したら昇格
3. 各候補について SKILL.md の雛形を提案する

あとはいつも通りセッションを開始して、SKILL.mdを読み込ませて「Skill化すべきパターンを見つけて」と頼むだけですね。ちなみにModelはclaude-sonnet-4.6を指定しています。以下は実際に出力されたセッションの一部ですが、直近30日のセッションを分析して、繰り返されているパターンを候補として提案してくれています。

$ copilot ← セッション開始
> Skill化すべきパターンを見つけて

直近30日のセッションを分析しました。以下が候補です:

1. unit-test-generation（12回 / 3ブランチ）
   「テストを書いて」「ユニットテスト追加して」「spec を作って」が同じ意図
   → 高優先度: 複数ブランチで繰り返されている

2. edit-and-verify（15回 / 4ブランチ）
   Read → Edit → Bash(test) の編集検証フローが最頻出ワークフロー
   → 既に定型化されているのでSkill化の効果が高い

今回の具体例には記載していませんが、Skillsの内容によっては既存Skillsを分析させて、「逆にSkillを使った時の方がやり直し多いで。」だったり「一つのSkillに集約しすぎているから分割した方がいいで。」といったフィードバックも得られると思います。

まとめ

Coding Agentが開発と切り離せなくなった今、~/.copilot/は最早「自分自身の開発行動履歴」と言っても過言ではありません。

config.json, mcp-config.json: 自分のツール設定の全貌
session-state/: 207個のセッション、各セッションにevents.jsonl・workspace.yaml・checkpoints・files
events.jsonl: user.message, tool.execution_start, skill.invoked……行動の全記録

このデータを使うと、「どのプロジェクトで何時間何をしたか」「どのツールをよく使うか」「どんな意図の依頼が多いか」が全部分かります。さらに繰り返しパターンを検出すれば、Skill化すべき候補を見つけられると思いますし、もっと言えばSkillに留まらず、「自動化すべきワークフロー」やPremium Request消費の改善なども見えてくると思います。

まずはopen ~/.copilot/session-state/してみてはいかがでしょうか。きっと努力と涙の結晶が何百件も眠っているはずです...

2026-01-26

アウトプット2倍への挑戦。ハードな基幹システムの移管を打開する「SPACE」の“S”向上戦略

はじめに

こんにちは。テクノロジーグループでエンジニアリングマネージャー（EM）をしている八巻（@hachimaki37）です。

今、私たちのグループは、Rails + Vue.js on AWS（ECS）で構築された10年運用中の基幹システムをNext.js on Salesforceへ移管するプロジェクトを推進しています。移管期間は1年間という、控えめに言ってもハードなミッションに挑んでいます。

2025年4月にプロジェクトはスタートし、2026年4月の本番リリースを完遂するためには、昨年度の開発アウトプット量では、物理的にロードマップの達成が不可能なことが分かっていました。

この絶望的なギャップを埋めるために、私たちが導入した武器が、開発生産性フレームワーク「SPACE」です。

特に、定性的で後回しにされがちな「S：Satisfaction and well being（満足度と幸福度）」を戦略的にハックし、前期比でアウトプット量（PRマージ数）が195%まで引き上がりました。

今回は、その「それっぽくも真剣な」改善の裏側を書いていきます。

注記：

プロジェクトはまだ道半ばです。この取り組みは、アウトプット向上の一つの取り組みでしかありません。
SPACEについての詳細説明を省いておりますので、適宜専門記事等をご参照いただけますと幸いです。もしよろしければこちらをご一読いただけますと幸いです。

グループの変遷

本編に入る前に、私たちのグループの変遷について触れておきます。以下は、2024年12月から2026年1月までの推移です。

現在、私たちのグループは職能を横断した9名の「クロスファンクショナルチーム」で構成されています。

Manager：1名
PdM：1名
Engineer：5名
SRE：1名
UI/UX Designer：1名

戦略の全体像

2026年4月のリリースをデッドラインとしたとき、ハードなプロジェクトを攻略するために、精神論ではない以下の3つの因子を成功の柱と定義し、2025年4月から推進してきました。

開発生産性の向上（デリバリースピード）：昨年度の開発アウトプット量では、どう計算してもロードマップに届きませんでした。AI活用を主軸としたデリバリースピードを探求し、アグレッシブに「デリバリー能力を改革する」必要がありました。
メンバーのエンゲージメント向上およびリスクマネジメント：大掛かりな移管プロジェクトを完遂する上で、恐るべきリスクは「人の離脱」と「心理的疲弊による停滞」です。1年という長丁場において何より重要なのは、個々のメンバーが前向きに挑戦し続けられるコンディションを保つことです。そのためには「S」の充足こそがプロジェクトの生命線になると考えました。
現行システムの安定稼働：新たな基幹システムへリプレイスする一方で、現行システムが不安定になれば、エンジニアのリソースは奪われてしまいます。機会損失の回避と開発コスト最適化のため、現行システムの安定稼働は「必須条件」でした。新たな基幹システムの開発にリソースを集中させるため、現行の障害対応コストを最小化する必要がありました。

これら3つの因子の問題を一つひとつ解消し続けた結果、一人ひとりの飛躍的な成長と活躍により、現在、ロードマップは達成基準を上回るペースで進捗しています。

ここからは、その中でも特に「2」の改善にどう取り組んだのか、詳細をお伝えします。

Wevoxを利用したSの可視化と改善

Satisfaction and well beingは、目に見えにくい指標です。ピーター・ドラッカーの名言において、「測定できないものは改善できない」という言葉があります。そこで私たちは、エンゲージメントサーベイツール「Wevox（ウィボックス）」を導入しました。

特筆すべきは、これは会社全体で一律に導入されたものではなく、私たちのグループが独自に、意思を持って導入・活用しているという点です。

導入背景と「S」への想い

Satisfaction and well beingは、個々の充実感や心身ともに満たされた状態に対する指標です。これを測定することで、グループの状態の可視化が可能になります。その測定をもとに改善のサイクルを回し、より意義のある1on1や組織改善を行いたいと考えました。

また、私がグループ運営において最も大切にしているのは、自分たちのグループ、そして自分自身に責任を持ち、充実感や心身ともに満たされた状態を「会社に委ねる」のではなく「自らの意思で作っていく」ことです。マネージャーだから、メンバーだからといった役割の垣根を超え、全員が当事者として「自分たちの手で、自分たちを変革していく」組織でありたいと強く願っています。

なぜなら私たちは、「成長産業支援プラットフォーム」への進化を目指し、共にイノベーションを起こして新しい時代を創る企業であるからです。単なるシステム開発集団ではなく、私たち自身の変革こそが、社会を変える原動力になる。その根幹にあるのは「自らを進化させ続ける力」に他なりません。組織と個人のありたい姿の重なりを増やし、互いを高め合える幸せな関係を築いていけるといいですよね。

利用目的

Wevoxの利用目的は、以下です。

可視化による改善：グループおよびメンバーの状態をデータで捉え、具体的なアクションに繋げること。
自走する組織づくり：マネージャー/メンバー参加型で当事者意識を持ち、自分たちで自分たちのコンディションを再現性を持ってコントロールできるようにすること。

実施方針

私たちは、四半期に1回の頻度で計測しています。これは、日々のコンディションを追う「パルスサーベイ」よりも、組織の構造的な課題や文化の浸透度をじっくり捉える「センサスサーベイ」に近い使い方をしています。短期的な一喜一憂ではなく、中長期的な組織の「健康診断」として活用しています。

これまでの実施回数は以下の通りです。

一回目：2025年06月
二回目：2025年09月

一回目の結果

初回のWevoxスコアは「B+(80)」と水準は高いものの、詳細を分析すると中身には深刻な課題が見えていました。

Good要素

Bad要素

見えてきた最大の問題は、グループの「精神的疲弊」でした。スプリント単位で行っているレトロスペクティブや日常の定性評価を突き合わせて課題を分析していくと、ある仮説に辿り着きました。それは、メンバーを削っているのは高稼働による肉体的疲弊そのものよりも、「リリース後の不安」や「プラットフォームの制約による技術的な閉塞感」といった、精神的な不確実性（不安）なのではないか、ということです。

実施したアクション

今回のアクションにあたり、不安を「成長」と「納得」に変えることを全体方針に定めました。

6月の結果を受け、単なる休息を促すだけでは根本解決にならない、より構造的なアクションが必要だと判断しました。具体的には、以下の二つのアプローチを軸に据えました。

①1Q振り返りワークショップによる解像度の向上

解決すべきテーマを「不確実性要素の解像度向上」と「プロジェクト意義の再認識」に定め、7月にLean Coffeeなどを活用しながらいくつかのワークショップを実施しました。

ワークショップの様子

ここでは漠然とした不安（精神的負荷）を、可能な限り具体的かつコントロール可能な状態へと分解していきました。1年という長丁場では、日々の作業がどうしても定型的な移管に感じられ、閉塞感が漂ってしまいます。そこであえて今、プロダクトの未来という「意味」を接続し直すことで、作業を「価値創造」へと昇華させるための対話を重ねました。

②自己成長期間の創出とデリゲーション

スコアの低かった「自己成長」への打ち手として、デリゲーションに挑戦しました。

単なる作業の割り振りではなく、メンバー個々のキャリアに紐づく「挑戦」を、移管プロジェクトの中に強引にでも作る。これにより、「やらされている移管」から「自ら進めるリプレイス」へと、メンバーのマインドをシフトさせることを狙いました。

二回目の結果

四半期ごとの計測を実施した結果、9月のスコアでは、全体スコアに数値の変化は見られませんでした。ただし、項目に細かな変化が見られました。

上がった要素

前回比較

自己成長：+4（70 → 74）
- 成長機会：+6（76 → 82）
健康：+5（68 → 73）
- 仕事量：+5（71 → 76）
- ストレス反応：+6（65 → 71）
組織風土：+1（82 → 83）
- 挑戦する風土：+2（78 → 80）
- 部署間での協力：+2（86 → 88）

この数値の変化は、それぞれが自らの役割を拡張し、不確実性という「不安」に対して「どう立ち向かうか」を自ら考え、行動してきた結果だと考えています。

自己成長の要素において具体的には、意思決定の一部をメンバーへ委譲してきました。これはまだやりきれているわけではなく、道半ばではありますが、メンバー一人ひとりが自らの判断で「自分の領域」を広げる手応えを少しずつ感じ始めているのではないかと考えています。

下がった要素

前回比較

人間関係：-5（87 → 83）
- 上司との関係：-5（88 → 83）
- 仕事仲間との関係：-3（87 → 84）
承認：-2（78 → 76）
- 発言・意見に対する承認：-10（92 → 82）
理念戦略：-3（80 → 77）
- 事業やサービスへの誇り：-4（69 → 65）

実施したアクション

一方で、人間関係や承認のスコアが微減（-5〜-10）した場面もありましたが、これはプロジェクトが佳境に入り、意思決定に伴う健全な対立が増えた結果と捉えています。これらは個別のフォローで解決するフェーズへと移行しています。

また、理念戦略における「事業やサービスへの誇り」へは、理念戦略に訴求するような「25年度下期キックオフ」を10月に実施しました。

主にこの場では、「グループのコラボレーション促進」と「下期方針の理解」を目的に実施してきました。

結果と成果

この取り組み以外にもグループで様々な改善を進めてきました。その前提ではございますが、一定「SPACE」の“S”への戦略的な投資は、結実したと考えています。また、このプロジェクトにおいて、グループの人数を純増できたことも大きな成長の一つですが、人数が2倍になったからアウトプットが2倍になったわけではありません。紆余曲折がありました。

エンジニア間はもちろんのこと、PdMやデザイナーとの緊密な連携なしには、アウトプット2倍への挑戦は到底見込めませんでした。限られたリソースの中でいかに個々のパフォーマンスを最大化し、チームとしての出力を高めるか。その組織の質へのアプローチこそが、今回の195%という数字の根幹であると考えています。

①開発生産性の向上

1人あたりのプルリク作成数（開発フェーズによるトレンドがあるため参考程度に）

プルリク作成数：194%（前期比）

マージ済みプルリク数：195%（前期比）

開発生産性スコア：2025年4月から「Elite」ランクを継続達成

Findy Team+ よりデータを引用

②現行システムの安定稼働

変更障害率：約30%ほど改善
平均修復時間：目標指標を大幅に下回るスピードで解決

さいごに

9名のクロスファンクショナルチームが、前期の約2倍の速度で邁進し続けています。この高い壁を乗り越えるためには、厳格な管理で縛ることではなく、チームが最大限に輝ける“S”の状態を戦略的に作り、維持することがはるかに重要であると考えています。

開発はまだ道半ばです。今回の“S”向上戦略を通じて、自分たちの状態を可視化し、対話によって自ら変革していくことの重要性を会得できたことは、チームにとっても大きな財産になったのではないかと思います。

これからも、数字と心の両面に向き合い、このハードなミッションの完遂に挑んでいきたいと思います。

2025-12-23

【GitHub Actions】actions/ai-inferenceを活用して痒いところを自動化しよう

GitHub Actions AI

name: 'AI inference'
on: workflow_dispatch

jobs:
  inference:
    permissions:
      models: read
    runs-on: ubuntu-latest
    steps:
      - name: Test Local Action
        id: inference
        uses: actions/ai-inference@v1
        with:
          prompt: 'Hello!'

      - name: Print Output
        id: output
        run: echo "${{ steps.inference.outputs.response }}"

公式引用

また、利用可能なモデルのカタログは以下で検索できますので興味ある方は見ていただけると色々試せて面白いと思います。

github.com

なぜactions/ai-inferenceなのか？

「Claude Code GitHub ActionsやGemini CLI GitHub Actionsもあるじゃん？」と思われるかもしれません。

確かにこれらは非常に強力なのですが、組織（人）によっては導入までの「社内調整コスト」に大きな差があると個人的には考えています。

他のAI Actionsとの比較

項目	actions/ai-inference	Claude / Gemini
認証	`GITHUB_TOKEN` でOK	API キー管理など
契約	GitHub 契約内で利用可能	ベンダーごとの契約・決済登録が必要
用途	日々の運用自動化（要約・分類）	ガッツリ機能開発・コード修正

特に「認証」と「契約」の壁は無視できません。

Claude Codeには無料割り当てがなく、利用には契約や課金が必須ですし、Gemini CLIにはGoogle AI Studioの無料枠はありますが、コードがAIの学習に用いられてしまうため、組織で活用する場合は無料枠を使う選択肢は実質ないと思います。

一方GitHub Modelsは、各GitHubアカウントごとに無料枠（ただしレート制限あり）が割り当てられており、コードが無断で学習に用いられることはありません。

「PRの要約や社内リリースノートを自動化したいだけなのに、予算を決めて、稟議を通してSecretsキーを発行して...」というのは、正直気が滅入りますよね。私は滅入ります。

そんな同志たちにこそ是非おすすめです。

docs.github.com

実践：リリースノート自動生成ワークフロー

では、実際に「痒いところ」を自動化してみましょう。

解決したい「痒いところ」

私のチームでは、PRをマージした後にSlackで「これリリースしました」と報告する運用があるのですが、変更内容をまとめて書くのが地味にめんどくさい瞬間があります。

文化的に（チームへの）リリース報告では詳細の報告も特段していないので、変更内容が知りたければIssueやPRまで個々で見に行く必要があります。

そこで、「mainブランチにマージされたら、GitHub ModelsがPRの内容を要約して、Slackにリリースノートを投稿する」ワークフローを作ってみました。

権限設定（最重要）

このアクションを使うには、permissionsブロックでmodels: readを許可する必要があります。これがないと動きません。

jobs:
  summarize-release:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      models: read # <--- これがAI呼び出しに必要！

AIアクションの呼び出し

PRの取得方法に関しては本題から逸れるので詳細省きますが、ghコマンドやGraphQLを駆使してPRのコミットメッセージやタイトルを取得します。

# 一部抜粋
PR_NUMBER="${{ github.event.pull_request.number }}"

# PRの基本情報とコミット情報のみを取得（コメント、レビュー、差分は除外）
gh pr view $PR_NUMBER --json title,body,number,author,url,commits,baseRefName,headRefName > pr-info.json

# ベースブランチとヘッドブランチを取得
BASE_REF=$(jq -r '.baseRefName' pr-info.json)
HEAD_REF=$(jq -r '.headRefName' pr-info.json)

# 差分の統計情報のみを取得（git diff --stat で要約）
git diff --stat origin/$BASE_REF...origin/$HEAD_REF > pr-diff-stat.txt

# PR情報を整形してファイルに保存
cat > pr-context.txt << 'EOF'

あとはとてもシンプルで、以下のようにai-inferenceのプロンプトに上記取得した内容を渡してやるだけです。

- name: Generate release notes with AI
  id: ai-inference
  uses: actions/ai-inference@v1
  model: openai/gpt-5-mini # モデルを指定
  max-tokens: 4000 # 生成するトークンの最大数

  prompt: ${{ steps.read-context.outputs.context }}  # 前段Stepで取得したPRの内容
  system-prompt-file: './path/system-prompt.txt'  # システムプロンプトのfile pathで指定できる

今回の例だとこんな感じのリリーステンプレートにしました。

渡されたPRの内容を元に、リリースノートを作成してください。
リリースノートは以下のフォーマットに従い、日本語で記述してください。

## やったこと
(30〜100文字程度で要約)

## 主なリリース内容
- (箇条書きで主な変更内容を列挙)
- (該当がなければ「なし」と記載)

## マイグレーションの有無
 (データベースマイグレーションやインフラ変更が必要な場合は詳細を記載、なければ「なし」)

## 注意点
- (デプロイ後の動作確認事項や注意すべき点を記載)
- (該当がなければ「なし」と記載)

Slack通知

あとは、適宜Slackアプリを作ってWebhookなり、chat.postMessage API（OAuthトークン）なりでSlack通知するように組めば完了です。

- name: Slack通知
  uses: slackapi/slack-github-action@v1.24.0
  with:
    payload: |
      {
        "text": "🎉 リリースされました！\n\n${{ steps.ai_summary.outputs.answer }}"
      }
  env:
    SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

これで、mainにマージされるたびに自動でリリースノートが流れるようになりました。やったー

その他の活用アイデア

他にも、以下の使い方を検証中です。「こんな使い方してます」というのがあれば何卒ご教授ください🙏

Issueの自動トリアージ
- Issueが起票されたら、「バグ」か「機能要望」かをAIに判断させて自動でラベルを貼る。
エラーログの自動解析
- ビルド落ちした時に、膨大なログから原因と修正案をAIに提示させる。

まとめ

actions/ai-inferenceは、面倒な設定なしでGitHub ActionsにAIを組み込める便利なツールです。

非常にハードルは低いので、まずは「PRの要約」や「Issueの自動トリアージ」といった小さなタスクから試してみてはいかがでしょうか？「これ、GitHub Modelsにやらせてみましょう」とチームに提案して、開発体験を向上させていきましょう！

2025-12-22

これからAWS認定資格を受ける人へSAA・DVAの勉強方法と所感まとめ

テックブログのアイキャッチ画像

はじめに

こんにちは。フォースタートアップス株式会社でエンジニアをしている田畑です。

私は入社してそろそろ2年になりますが、最近はインフラ周りの業務に携わる機会が徐々に増えてきました。弊社ではAWSを利用しており、日々業務で触れるリソース以外にも、より幅広い知識を体系的に身につけたいと思い、AWS認定資格の取得に挑戦しました。

本記事では、実際にAWS認定資格（DVA・SAA）を取得した経験をもとに、試験の概要・勉強にかかった時間・準備方法・実務への活かし方などをまとめてお伝えしていきます。

AWS認定資格とは?

AWS認定資格は、Amazon Web Services（AWS）に関する知識やスキルを客観的に証明するための公式認定資格です。大きく以下の4つの分野に分かれています。

Foundational（基礎）

Cloud Practitioner
AI Practitioner

AWS認定資格の中でも最も難易度が低く、AWSに関する用語や基本的な概念など、基礎的な知識を身につけることができます。

Associate（中級）

Solutions Architect
Developer
CloudOps Engineer
Data Engineer
Machine Learning Engineer

AWSの実務経験が1〜2年程度の初級エンジニア向けの資格です。実務で求められる知識や、各認定資格の観点に沿ったAWSリソースの理解を深めることができます。

Professional（上級）

Solutions Architect
DevOps Engineer
Generative AI Developer

AWSの実務経験が2年以上あるエンジニアを主な対象とした資格で、AWSを用いたシステム設計や運用において、実務経験に基づく高度な判断力が求められる上級者向けの認定資格です。

Specialty（専門）

Machine Learning
Advanced Networking
Security

特定の分野に関する専門的な知識と実務レベルでの深い理解が求められる、専門特化型の認定資格です。クラウド未経験〜初級であれば、多くの人はCloud Practitioner（CLF）またはSolutions Architect Associate（SAA）から始めるケースが多いです。

参考：AWS 認定

なぜAWS認定を受けようと思ったか

今回、私が取得したAWS認定資格は以下の2つです。

AWS Certified Solutions Architect – Associate（SAA）

可用性や冗長化といった観点から、システム全体の設計を理解していることが求められる資格です。

AWS Certified Developer – Associate（DVA）

AWS SDKやLambda、API Gatewayなどを用いた、アプリケーション開発者視点でのAWS利用に関する理解が求められる資格です。

AWS認定資格を取得しようと思ったきっかけは、実務で日常的に触れているAWSリソースが、全体の中ではごく一部に限られており、これまで使ったことのないリソースについても幅広く理解したいと感じたことでした。

普段の業務では、S3やLambdaなど、アプリケーションと連携して利用されるサービスに触れる機会が多くあります。例えば、アプリケーションからS3にファイルをアップロードし、そのイベントをトリガーにLambdaを実行するといった構成で利用しています。一方で、ネットワーク設計やセキュリティ周りのサービスについては、実務で直接触れる機会が少なく、体系的に学ぶ必要性を感じていました。

その中でも、今回取得した2つの資格は、日々の業務に直結する実践的な内容を体系的に学べると考え受験しました。DVAでは普段利用しているLambdaやS3についてより深く理解すること、SAAではシステム全体のアーキテクチャを俯瞰して捉えられるようになることを期待していました。

勉強方法

まずは、対象資格の参考書を一通り読みました。その後は、Udemyで購入した模擬試験問題集を中心に、繰り返し問題を解く学習方法を取りました。参考書については、すべてを暗記しようとするのではなく、全体像を把握する目的でさらっと読み進め、理解が浅かった部分や重要そうなポイントを、問題演習を通じて復習するようにしていました。

Udemyの問題集では、回答後に各選択肢で登場するAWSサービスの概要が図解付きで解説されており、単なる正誤確認にとどまらず、サービス理解を深めるのに役立ったと感じています。

また、より深く理解したいテーマについては、AWS Black Belt Online Seminar を活用しました。これはAWS Japanが提供している公式の技術解説セミナーシリーズで、サービスの背景や設計思想まで含めてキャッチアップできるため、知識の補完として非常に有用でした。

個人的な感覚としては、参考書だけでの合格はやや厳しい印象です。参考書の巻末に付属している模擬問題は、内容理解の確認という位置づけで難易度も比較的易しく、実際の試験レベルを想定すると、問題演習量が不足しがちだと感じました。とはいえ、参考書のみで合格している方の声も多く見かけるため、学習の進め方次第では十分対応可能だと思います。当たり前ですが、自分に合った学習スタイルを見つけることが重要だと感じました。

使用した教材

Udemy

参考書

※ 本記事で掲載している参考リンクは、すべてアフィリエイトリンクではなく、純粋な情報共有を目的としたものです。

実際にかかった時間

DVA

勉強期間：2週間
平日：通勤中に30分
休日：3〜4時間

合計：23時間程度

SAA

勉強期間：1週間
平日：通勤中に30分、業務時間後に30分〜1時間程度
休日：5〜6時間

合計：15時間程度

今回の受験では、先にDVAを取得し、その直後にSAAを受験しました。直前まで学習していたDVAの知識をそのままSAAの試験でも活かすことができたため、結果としてSAAはDVAよりも少ない学習時間で合格することができました。

一方で、試験の難易度自体はSAAの方が高いと感じました。DVAはAWSリソースの使い方や特徴を理解していれば対応できる問題が多いのに対し、SAAではそれに加えて、要件に応じてどのようにアーキテクチャを構成するかといった設計観点が求められます。

そのため、もし受験順序が逆であった場合、SAAの取得にはより多くの学習時間が必要だっただろうと感じています。

試験会場（オンライン・オフライン）

AWS認定試験は、指定されたテストセンターで受験する方法と、自宅やワークスペースなどからオンラインで受験する方法の2通りがあります。

私は、DVAはテストセンターで、SAAは自宅からオンラインで受験しました。オンライン受験の場合、試験開始前に身分証明書のアップロードやネットワーク環境のチェックなど、事前準備が必要になりますが、移動時間や交通費がかからない点を考えると、個人的にはオンライン受験の方がメリットが大きいと感じました。

一方で、オンライン受験では、手の届く範囲に物を置かないことや、試験中に第三者が部屋に入らないことなど、受験環境に関するルールが厳しく定められています。そのため、事前に受験環境を整えておくことには注意が必要です。

実務に活かせるか？

私の場合は前述のとおり実務でLambdaとS3を利用していますが、学習を通じて「なぜLambdaを使うのか」という設計上の背景をより深く理解できるようになりました。S3イベントをトリガーとしてLambdaが起動する構成についても、単に動作を知っているだけでなく、その仕組みがどのようなユースケースに適しているのかを意識できるようになり、全体の解像度が上がった実感があります。

一方で、実務で使用する機会の少ないAWSリソースについては、時間の経過とともに知識が薄れていくのも事実だと思います。そのため、資格取得そのものが直接すべての実務に直結するというよりは、AWSに関する知識を体系的に整理したり、普段触れないサービスにも目を向けるきっかけとしての側面が大きいと思いました。

まとめ

今回は、AWS認定資格についてまとめてきました。インフラ領域に普段あまり触れない方であっても、クラウドに関する知識は持っておいて損はないと思います。

資格取得は、学習を継続するための良いモチベーションになりますし、AWSを体系的に学ぶための入口としても適していると思います。これからAWS認定資格の受験を検討している方にとって、本記事が少しでも参考になれば幸いです。

目次

はじめに

セッションログの全体像

config.json — 意外と多い情報量

session-state/ の構造

workspace.yaml — セッションのメタデータ

checkpoints/ — 作業の節目

files/ — セッション成果物の保存先

events.jsonl — 行動のフルログ

セッションログから読み取れること

Skillsへの抽出

実際にやってみた

まとめ

はじめに

目次

グループの変遷

戦略の全体像

Wevoxを利用したSの可視化と改善

導入背景と「S」への想い

利用目的

実施方針

一回目の結果

Good要素

Bad要素

実施したアクション

二回目の結果

上がった要素

下がった要素

実施したアクション

結果と成果

さいごに

目次

はじめに

actions/ai-inferenceとは？

なぜactions/ai-inferenceなのか？

他のAI Actionsとの比較

実践：リリースノート自動生成ワークフロー

解決したい「痒いところ」

権限設定（最重要）

AIアクションの呼び出し

Slack通知

その他の活用アイデア

まとめ

目次

はじめに

AWS認定資格とは?

Foundational（基礎）

Associate（中級）

Professional（上級）

Specialty（専門）

なぜAWS認定を受けようと思ったか

AWS Certified Solutions Architect – Associate（SAA）

AWS Certified Developer – Associate（DVA）

勉強方法

使用した教材

Udemy

参考書

実際にかかった時間

DVA

SAA

試験会場（オンライン・オフライン）

実務に活かせるか？

まとめ