Takumi Runnerのcicd-sensor連携に無料枠ができたので、早速試してみた

はじめに

CI/CDのランタイムオブザーバビリティのOSSであるcicd-sensorについて、Flatt SecurityのTakumi Runnerへのトレース連携に無料枠ができたということで、早速試してみました。

Takumi Runnerのcicd-sensor連携にて、無料枠が提供開始されました！
クレジットカード登録なしで、Takumiの組織を作成するだけで毎月3,000分までCI/CDの実行トレースを取り込めます。
ソフトウェアサプライチェーン侵害などの脅威検出を無料枠の範囲でお試しいただけます。https://t.co/FcIz8PvdhZ

— GMO Flatt Security株式会社 (@flatt_security) September 1, 2026

そもそもランタイムオブザーバビリティとは何か、そのなかでcicd-sensorはどう位置づけられるかについては、以前の記事「続・AIコーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術」をご参考ください。

こんな方におすすめ

• Takumi Runnerのcicd-sensor連携がどういうものか知りたい方

cicd-sensor連携を設定する

概要と設定方法については以下の記事をご確認ください。

基本の設定は記事の通りさっと終わるのですが、私の場合は、

• 個人で利用しているGitHubの無料枠であること
• 同一リポジトリの複数のActionで連携を利用したい

ということから、以下のようなactionを作りました。

.github/actions/cicd-sensor/action.yaml

name: Send traces to Takumi Runner
description: ジョブの実行トレースを cicd-sensor で拾って Takumi Runner に送る

inputs:
  bot-id:
    description: Takumi のボット ID。空なら何もしない（未設定のリポジトリで落とさない）
    required: false
    default: ""

runs:
  using: composite
  steps:
    - id: takumi
      if: inputs.bot-id != ''
      continue-on-error: true
      uses: flatt-security/shisho-cloud-action@9b68d33503ebf75d7c285d489b288f96ef3df758 # v1.1.0
      with:
        bot-id: ${{ inputs.bot-id }}
        export-token: true
        expires-in-minutes: 60

    # takumi がスキップでも失敗でも token は空になる
    - if: steps.takumi.outputs.token != ''
      continue-on-error: true
      uses: cicd-sensor/cicd-sensor-action@6511eb44c91d71b2b93d71193b1bf2cb18352f66 # v0.0.38
      with:
        manager-url: https://manager.cicdsensor.cloud.shisho.dev
        manager-token: ${{ steps.takumi.outputs.token }}

これを各Actionのcheckoutの後に設定します。

.github/workflows/workflow.yaml

jobs:
  check:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
    timeout-minutes: 3
    steps:
      - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
        with:
          persist-credentials: false
      - uses: ./.github/actions/cicd-sensor
        with:
          bot-id: ${{ vars.TAKUMI_BOT_ID }}
      - uses: ...

GitHub Actionsの設定としてはこれで完了です。

なお詳細は割愛しますが、GitHub ActionsとTakumi Runnerコンソールとの連携はOIDC形式になっており、Organization / UserとRepositoryを指定することで信頼条件を設定するようになっていました。

Takumi Runnerで連携されたトレースを確認する

つい最近Claude Code Actionsを使ったリサーチ用のエージェントを作成していたので、そのリポジトリのCI/CDに対して実装してみました。

トレースが適切に連携できると、Takumi Runnerのジョブのコンソールに実行されたジョブの一覧が表示されるようになります。それぞれのActionのジョブが連携されていることがわかります。

ここからは、特に好き勝手動きがちなAgentが動いているジョブを例に見ていきます。

まずは概要です。プロセス実行、ネットワーク、ファイルアクセスの概要がざっとまとまっています。

続いてプロセス実行です。実行順に一覧表示されます。

ネットワークは、外部サービス、GitHub Actions、パッケージレジストリ、Runnerインフラの区分ごとに表示されています。

ファイルアクセスについては、ディレクトリの単位をベースに、ファイルレベルまでドリルダウンして確認することができます。

最後にクエリです。DuckDBでクエリを実行することで個別のログを探索することができるようになっています。

15分以上エージェントが動き回ったジョブではトレースログが多すぎて、ロードがすぐに終わらなかったため別のものを例にしました。（全体で2万件くらいログがあるようなので仕方がない・・・）

なお、cicd-sensorの場合は以上のようになっていますが、Takumi Runnerからの連携ではプロセスの親子関係とワークフロータイムラインも確認できるとのことです。

CI/CDのトレースをどう扱うか

先日技術検証していたときに、cicd-sensorでCI/CD環境のモニタリングができるというのはそれはそれで非常に価値のあることですが、一方でここからどう対策につなげていくのがいいのか？というのは難しいことに感じていました。

それに対して、Takumi Runnerのコンソールのように、一定のデータの集約、ビューが整理されていることは、モニタリングしていく上では非常に役立つことのように思います。

とはいえ、いちいちログを見に行くなどというめんどくさいことはなかなか人間がやるのはつらくなってくるところ。そこで、連携したログを元に即時／事後検知が行われ、その後にその影響範囲の整理のために確認のための探索をするというのが現実的な運用になるのではないでしょうか。

そういう意味でも、その部分をFlatt Securityのようなセキュリティ専門会社に委ねていけそうなこういった連携はとても便利なものに思えました。

おわりに

これ、とてもいい！ということでみなさんもぜひご利用ください！（と言いつつ業務利用はできていない・・・）