変更要約: GH-200 第3章を新規作成（カスタムアクションの作成＝JavaScript/Docker/コンポジットの種別と選択・action.yml メタデータ・inputs/outputs・ワークフローコマンド・トラブルシュート、配布と保守＝公開/プライベート/Marketplace・Marketplace 公開手順・タグ/リリース/メジャータグ移動/SHA ピン留め・@main 回避・不変アクション）
3.1カスタムアクションの作成 — 種別・メタデータ・入出力
アクションの 3 つの種別（JavaScript・Docker コンテナ・コンポジット）と選び方、action.yml に書く必須ファイルとメタデータ（inputs・outputs・runs・branding）、アクション内でのワークフローコマンドの利用、そしてアクション実行エラーのトラブルシュートを理解します。
アクション は、ワークフローのステップから uses: で呼び出す 再利用可能なコードの単位 です。Marketplace の既製アクションを使うだけでなく、自分のロジックを カスタムアクション として作って配布できます。アクションには 3 つの種別 があり、要件に応じて選びます——JavaScript（または TypeScript）で書く JavaScript アクション、任意の言語/ツールを Docker コンテナ に閉じ込める Docker コンテナアクション、そして複数のステップを束ねる コンポジットアクション（第2章で既出）です。
3.1.13 種別の特徴と選び方
JavaScript アクション は Node.js で動き、起動が速く、Linux・Windows・macOS の各ランナーで動作します（クロスプラットフォーム）。依存をバンドルして配布します。Docker コンテナアクション は、特定の OS パッケージや言語ランタイムを同梱でき環境を完全に制御できますが、Linux ランナー限定 で、イメージのビルド/取得のぶん起動は遅くなりがちです。コンポジットアクション は、既存のステップ（run: や他アクションの uses:）を YAML で束ねる もので、シェル中心の手順をまとめるのに向きます。「速くクロスプラットフォーム＝JavaScript」「特殊な依存/言語が必要＝Docker」「既存ステップの集約＝コンポジット」と整理します。
| 種別 | 実行基盤 | プラットフォーム | 向くケース |
|---|---|---|---|
| JavaScript | Node.js | Linux/Windows/macOS | 速い・クロスプラットフォーム |
| Docker コンテナ | コンテナイメージ | Linux 限定 | 特殊な依存/言語の同梱 |
| コンポジット | 複数ステップの束 | ランナー依存 | 既存ステップの集約 |
3.1.2action.yml — メタデータと入出力
どの種別でも、アクションのルートに action.yml（または action.yaml）という メタデータファイル を置くことが必須です。ここで name・description、受け取る inputs（型・必須・既定値・説明）、返す outputs、そして実行方法を表す runs を定義します。runs.using は種別に対応し、JavaScript なら node24（node20 は 2026/4 で EOL・ランナー既定は 2026/6 から node24）＋main:、Docker なら docker＋image:、コンポジットなら composite＋steps: を書きます。branding で Marketplace 表示用のアイコン/色も指定できます。入力はワークフローの with: から渡され、アクション内では環境変数 INPUT_<名前>（JavaScript なら @actions/core の getInput）で読みます。
3.1.3アクション内のワークフローコマンド
アクションは ワークフローコマンド を使ってランナーと対話します。出力を設定する echo "name=value" >> "$GITHUB_OUTPUT"、環境変数を後続へ渡す $GITHUB_ENV、ログのアノテーション ::notice::/::warning::/::error::、秘密値を伏せる ::add-mask::、ログの折りたたみ ::group::/::endgroup:: などです。JavaScript アクションでは @actions/core（setOutput・setFailed・info・setSecret など）を通じて同じ操作を行います。これにより、アクションは結果（outputs）や状態をワークフローへ正しく伝えられます。
3.1.4アクションのトラブルシュート
アクションが失敗するときは、まず action.yml の整合性（runs.using と実体、inputs/outputs 名の一致）を確認します。JavaScript アクションでは 依存のバンドル漏れ（node_modules を含めず公開して Cannot find module になる）が典型で、@vercel/ncc 等でバンドルして単一ファイルにするのが定石です。Docker アクションでは イメージのビルド失敗・権限・エントリポイントを疑います。共通して、::error:: アノテーションと（必要なら）デバッグログで原因を特定します。
頻出：
①JavaScript アクション＝速い・クロスプラットフォーム。Docker コンテナアクション＝特殊依存を同梱できるが Linux 限定で起動は遅め。コンポジット＝既存ステップの束。
②必須は action.yml（name/description/inputs/outputs/runs.using＝node24|docker|composite）。
③入力は with:→INPUT_<名前>/getInput、出力は $GITHUB_OUTPUT/setOutput。
④JS アクションは依存をバンドル（ncc）。
混同・注意：
①Docker コンテナアクションは Linux ランナー限定——Windows/macOS では使えない。
②JavaScript アクションは node_modules をバンドルしないと Cannot find module で落ちる。
③コンポジットアクション（1 ステップとして使うアクション）と再利用可能ワークフロー（ワークフロー全体を呼ぶ）は別物（第2章）。
④runs.using の値（node24 / docker / composite）と中身が一致していないと起動しない。
3.1.5この節のまとめ
- 種別＝JavaScript（速い・クロスプラットフォーム）/Docker（特殊依存・Linux 限定）/コンポジット（ステップの束）
- action.yml が必須：name/description/inputs/outputs/runs.using（node24|docker|composite）
- 入力は with:→INPUT_<名前>/getInput、出力は $GITHUB_OUTPUT/setOutput、ワークフローコマンドで状態を伝える
- JS は依存をバンドル（ncc）、Docker はビルド/権限/エントリポイントを確認
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 作成するカスタムアクションを Linux・Windows・macOS のすべてのランナーで動かし、起動も速くしたいです。最適な種別はどれですか？
Q2. 特定バージョンのシステムパッケージや独自言語ランタイムを同梱して環境を完全に制御したいアクションを作ります。適切な種別と制約はどれですか？
Q3. カスタムアクションのルートに必ず置き、name・inputs・outputs・runs を定義するファイルはどれですか？
Q4. JavaScript アクションを公開したところ、利用者の実行で「Cannot find module」が頻発します。最も可能性が高い原因と対策はどれですか？
Q5. アクションの処理結果（生成したタグ名など）を、呼び出し元のワークフローの後続ステップで使えるようにするにはどうしますか？
Q6. ワークフローの with: で渡された入力を、コンポジット/シェルのアクション内で読む標準的な方法はどれですか？