要約

  • LACNICの公開Hackathonリポジトリは、エージェントに共有ai-harnessの規則を読ませ、activeモードでは変更作業の前に更新も求める。ところがGitツリーに保存されているのは、../ai-harnessを指す13バイトのシンボリックリンクだけだ。
  • そのためHackathon側のコミットから確認できるのは入口と相対パスまでで、外部リポジトリのURL、固定コミット、ダイジェストは分からない。外部指示の実体を記した実行証跡があれば、共有ハーネスの機動性を失わずに変更の再現性を確保できる。

長い規程より、13バイトの方が強い権限を持つことがある。LACNIC/hackathonの現在のツリーでは、ai-harnessはモード120000で記録されている。Git上のシンボリックリンクであり、blobを展開すると内容は../ai-harnessだけである。

この構成には明確な利点がある。レビュー手順、テスト方針、開始前チェックを共通化すれば、複数のプロジェクトに同じ改善を一度で反映できる。9月の変更も、統制を弱める内容ではない。maintenanceとactiveを分け、状態を変える作業にはクリーンな標準checkoutを求め、linked worktreeでは開始しないよう明記している。

論点はリンクの採否ではなく、版の同一性である。Hackathonのコミットは、自身のAGENTS.mdとリンクblobを厳密に特定する。しかし、エージェントが最初の1行を読み、更新スクリプトを動かし、事前検査を受けた時点で、隣のディレクトリにどのリポジトリのどのコミットが置かれていたかまでは特定しない。

参照先は補足資料ではない。9月版AGENTS.mdは、どのコマンドより先にai-harness/AGENTS.mdの1行目だけを読み、AI_HARNESS_MODEを適用するよう求める。maintenanceならハーネスの更新、同期、実行を禁じる。activeなら./ai-harness/harness/framework/update-framework.shを実行し、その後に全体の規則を読む。さらに、状態変更を伴う新しいセッションの前にgit-preflightを通す。

つまり外部checkoutは、適用規則、更新の有無、変更開始の条件を左右する。同じHackathonコミットを持つ2台の環境でも、../ai-harnessの版が違えば、モード行や更新処理、事前検査が違い得る。実際に差異が起きたと示す資料はない。確認できるのは、HackathonのSHAだけでは指示環境全体を復元できないという点までだ。

7月の導入と9月の精緻化

2026年7月12日のコミット16c37db9fe6e1c1b0bc7260b744ee7595a10de67は、「chore: adopt shared ai-harness」という説明でローカルの入口、相対リンク、プロジェクト固有の雛形を追加した。新しいセッションの前に共通フレームワークを非対話で更新し、その規則表を読む構成はこの時点で入っている。

9月8日のa68504f87dd5226238bb65b62b89d40419ed7c1fは契約を細分化した。2つのモードを定め、maintenance中の読み書きを狭め、事前検査が標準かつクリーンなcheckoutを要求すると記した。変更は6f9f60846acb30d4dcbf3969908743671c4a2921としてマージされた。

マージ後のツリーはAGENTS.mdをblob 34e8fb06a0d71b939283dea4d77381ff029ad981に結び、ai-harnessリンクをblob 2244dfc17eaa1d54869e0bb3ff01ff258c6b0a0eに結ぶ。後者のサイズは13、モードは120000である。これらはHackathonリポジトリ内部のオブジェクトを十分に識別するが、別リポジトリのコミットを指すgitlinkではない。証明するのは相対パスだけだ。

入口文書には、参照先のGit URL、タグ、固定コミット、内容ダイジェストがない。別のセットアップ手順や端末イメージが厳密な版を指定している可能性は残る。公開資料から「指定が存在しない」とは言えない。言えるのは、Hackathonコミットの証拠境界に含まれていないということだ。

最新版を使いながら、版を残す

共通ハーネスを永久に固定する必要はない。中央の修正をすぐ取り込めること自体が価値だからだ。実行時の選択と、実行後の記録を分ければよい。

開始時に「承認済みの最新版」を解決し、解決後のリポジトリURLと不変コミットを記録する。更新前がA、更新後がBなら、両方と更新結果を残す。新しさと再現性は二者択一ではない。

SLSA 1.2のprovenanceは、複雑な供給網の可動部分をたどり、成果物がどこで、いつ、どのように作られたかを示す検証可能な情報と説明される。LACNICがこの作業にSLSAを採用したと述べているわけではなく、エージェント規則をそのままビルド成果物とみなす必要もない。ここで有効なのは、動く依存先の解決済みIDを結果に添える、という限定的な考え方である。

規則本文より短い受領記録

必要な記録は大きくない。Hackathonコミット、リンクblob、外部リポジトリのURLと固定コミット、読み取ったAI_HARNESS_MODE、update-framework.shの実行前後の版、git-preflightの版と結果、標準checkoutとworktreeの識別情報、時刻、実行を開始した人または自動化のIDを並べればよい。

更新に失敗した場合は、停止したのか旧版で続行したのかを分ける。モードが変わった場合は遷移を残す。後日規則を訂正するなら、過去を上書きせず、影響する実行記録に訂正をひも付ける。秘密情報やプロンプト、端末全体を公開する必要はない。残すべきなのは、変更を許可した技術的権限の正体である。

この記録はレビューにも効く。同じプロジェクトSHAから異なる結果が出たとき、コード差、データ差、モデル差より先に規則差を確認できる。過去の出力が古いプロジェクト、古いハーネス、またはその両方に由来するのかも切り分けやすい。

公開リポジトリは、セキュリティ事故、誤った結果、実運用への投入を証明していない。見えているのは、外部規則がモードを選び、更新を起動し、変更開始を判定するほど重要になったことだ。規則が行為を決めるなら、その版も行為の識別情報に含めるべきである。

情報源