開発記録・公開前候補 / UNKNOWN
確認日
OrcaとCodexで最初のMVPを作るまで――実装より難しかった、結果の確かめ方
編集状態: 公開候補・未公開。2026年10月20日時点の記録。独立した正確性・privacy・securityレビューは、2026年10月20日に非公開の編集候補として受入済み。公開には別途Ownerの承認が必要。
Kazunari Labsの最初のWeb MVPは、2026年10月20日に通常のPR mergeまで到達した。ただし、完成したのは非公開・ローカル検証用の静的サイトである。表示内容は合成fixtureで、実製品の調査結果を公開したわけではない。今回記録したいのは、Orca上のCodexを使ってコードを書く流れと、その成果を「確認できた」と判断するまでの過程だ。[E5]
最初に見えた課題は、作業量よりも証拠の境界だった。Workerが完了してもParentが止まっていることがある。役割らしい名前を付けても、実際にはその役割で動いていないことがある。ブラウザーを操作できても、決めた性能試験を実行できるとは限らない。この三つを曖昧にすると、整った完了報告だけが先にできてしまう。
小さなサイトに、明確な担当を置く
今回の分担では、ParentがIssueの要件・依存・所有権を確認し、WorkerがIssue専用のworktreeとbranchで実装する。Reviewerは実装担当と分け、レビューしたcommitを記録する。Parentがそのcommitのローカル検証、実際のCI、GitHub上のmerge条件を照合して統合する。Ownerはscopeと、公開や運用有効化など別の判断が必要な境界を決める。[E1, E5]
worktreeは作業ファイルを分ける仕組みであり、この分担だけで各エージェントがOSレベルのsandboxに隔離されるとは扱っていない。また、同じGitHub actor配下のエージェントによる独立レビューを、別actorによるGitHub承認として数えていない。[E5]
サイト側も入力を絞った。リリース対象は明示された合成コンテンツとassetで、内容のhashを照合する。privateなObsidianノートを丸ごと同期する方式は採らず、未承認の入力を拒否する設計にした。自分用の作業記録と、読者に渡す文章を別の成果物として扱うことが、このMVPの前提になった。[E5]
何が、いつ確かめられたか
| 日付・時刻 | 記録から確認できたこと | その時点で意味しないこと |
|---|---|---|
| 10月18日 | 役割選択の調査で、監査対象の直近8 dispatchが明示的にdefaultを選んでいたと確認した。[E1] | タスク名がWorkerやReviewerなら、その役割になるという保証 |
| 10月19日 08:42:17 JST | 別製品の作業中にParentがserver_overloadedで異常終了。Workerは08:44:16に正常完了したが、ParentはOwnerの19:10:30の発言まで再開しなかった。[E2] | Worker完了によるParentの自動復旧 |
| 10月19日 UTC／20日 JST | UI試作品でキーボードの逆順到達を追加観測した。[E3] | 複数デザインツールの正式比較、勝者や採用判断 |
| 10月20日 04:10–04:13 UTC | 固定した旧候補5d6646eで、3ページ×3回のC9性能計測を実施した。[E4] | 最終merge版や全ページの再計測 |
| 10月20日 12:02:54 UTC | 204c227のLinux CI jobが成功。portable test 117件とリリース入力検証を実行した。[E5] | Linux上のブラウザー描画・サイトbuildの検証 |
| 10月20日 12:04:33 UTC | 同じreview済みheadを通常merge。merge commitは5e7e989。[E5] | 公開、deploy、実運用の開始 |
本稿の初稿準備時にremote mainを照合した値は5e7e98911741e77821a1c62b98f1303ebb97d23bだった。これはその時点の観測であり、将来もmainがこの値だという意味ではない。後続のコンテンツやUI変更の結果を、このMVPの検証結果へ混ぜない。[E6]
四つのつまずき
1. 名前では役割を選べなかった
10月18日の調査では、Parentがタスク別のmodelを選ぼうとして、agent_type=defaultを明示していた。WorkerやReviewerらしいタスク名は、runtimeのroleを選んでいなかった。確認できた原因はdispatchの選択であり、OrcaのUI不具合と断定する証拠はなかった。[E1]
修正した運用は、責務から明示的なroleを選び、そのroleのmodelとeffortを使い、実行時のrole・model・effortを照合するというものだ。画面の表示確認は別に扱う。これは指示による運用で、機械的な強制制御の完成を示すものではない。
2. Parentの沈黙を、作業完了と取り違えかけた
server_overloadedによる中断は、このサイト自身の障害ではなく、先行する別製品の実作業で起きた。約10時間28分の間、Parentの推論要求は0件と記録されている。Workerの正常完了だけでは、レビューやPR作成など次の工程が進む保証にならなかった。[E2]
ここから作った復旧支援は、明示したsessionの状態を照合し、確定した工程と不明な状態を分け、Ownerに再開候補を提示する隔離PoCだった。後に単発の通知TESTも確認されたが、常設監視、実障害通知、自動Parent再起動が稼働したという話ではない。再開時は、残された完了報告だけで動かず、GitHub・Git・作業場所の最新状態を取り直す。[E2]
3. 性能スキルと、実際に使える道具が合わなかった
C9は、指定した条件の3ページを各3回cold runし、LCPの中央値とCLSの最大値を確かめるローカル受け入れ試験だった。当初のactiveなweb-perfスキルは、Chrome DevTools MCPがなければ停止する指示だった。一方、そのsessionに必要なMCP toolは公開されていなかった。一般のブラウザー操作能力から、同じ性能試験ができるとは推定しなかった。[E4]
選んだのは、管理権限を確認したうえでの、その案件だけに限る有限のローカルpolicy例外だった。依存関係とlicenseを確認し、Lighthouse 13.5.0を固定し、最大9回・15分の範囲で測定した。終了後はactiveなスキルを元のbytesへ戻した。この履歴は、現在のスキルや他案件に同じ例外が使えるという許可ではない。[E4]
Lighthouse自体にはCLIなど複数の実行方法がある。しかし、その一般的な対応と、あるsessionで許可され実際に使える方法は別に確認する必要があった。Chrome公式のLighthouse説明
4. Billingの確認を、開発の前提にしすぎた
履歴にはCIの予算やpaid capを理由にした保留がある。最終的にはOwnerが、既に承認していた1回の軽量Linux CIと、条件を満たした通常mergeについて、追加のBilling調査を前提にしないと明示した。その範囲で1 jobを実行し、成功を確認した。Billing障害でrunnerが起動しなかった事例として扱っているわけではなく、Billing調査や支払い設定変更も行っていない。遅延の正確な時間や金額は、本稿では算出していない。[E5]
学びは、品質gateと、過去の文書に残った手続き上の保留を区別することだった。今回もテストやレビューは残し、承認済みscopeを工程ごとに承認し直すことは避けた。
数字は、測ったrevisionと条件に戻す
最終review対象204c227927227b8c012986f87b44aec6e45f1c4dでは、push後のローカル127件が成功した。二つの独立したbuild directoryで、それぞれtypecheck/buildが成功し、77ファイルがbyte単位で一致した。リンク、asset、privacy、faviconのHTTP status・MIME・hash、存在しないrouteの確認も記録されている。[E5]
Linux CIの117件は、この127件の失敗分を除いた数字ではない。ブラウザーを必要とする二つのtest fileを対象外にしたportable suiteであり、完全なリリース入力検証は4 records・1 assetを確認した。ブラウザーを伴うローカル検証と、軽量Linux CIは別の役割を持たせた。[E5]
C9は、さらに前の5d6646e3a57860e3cc402bc9bf6d9961caa744e2を測った値だ。[E4]
| 合成ページの種別 | LCP中央値 | CLS最大 |
|---|---|---|
| Home | 566.236 ms | 0 |
| Project detail | 555.020 ms | 0 |
| Research article | 542.300 ms | 0 |
条件はmacOS 26.6.2、Chrome 155.0.8059.85、Lighthouse 13.5.0、360×800 CSS px・DPR 1、相対CPU 4倍、request単位のlatency 150 ms、download 1.6 Mbps／upload 750 Kbps相当。9回の計測呼び出しは失敗・retryなしで、計176.610秒だった。指定目標のLCP中央値2,500 ms以下・CLS最大0.1以下を満たし、独立レビューも受けた。[E4]
これはpacket単位のRTT制御や実mobile回線の測定ではない。host全体のidle状態、browserの全background通信、計測記録のoverheadは完全には制御・定量化していない。各回にfaviconの404も一つ記録され、その後の修正を新たな性能計測とは数えていない。field INP、全10 routes、公開後の性能や完全なaccessibility適合の証明には使わない。labとfieldの条件差については、web.devの解説も参考になる。
比較できなかったことを残す
デザインツールの正式比較は、このMVPの成功物語に足していない。観測したのは単一の合成ローカル試作品の操作で、正式比較の各方式2試行は未実行、得点・総点・勝者・採用判断はなかった。account entitlement、費用、privacy、exportや画像の権利などのgateが残っていた。試作品が動いたことを、デザインツール比較の実証や実製品のresearch結果へ拡張しない。[E3]
実装、検証、通常mergeまでの到達は記録できた。一方、開発時間やtokenをどれだけ節約できたかを判定する対照実験はしていない。無人で開発を回せることも示していない。今回得た実用的な習慣は、結果の横にrevision・条件・未確認範囲を置くことだった。次にこのサイトを進める際も、この記録を出発点に、変更した部分を新しく確かめる。
出典とレビューの扱い
E1〜E6は、このケースの非公開一次記録に対応する編集用evidence IDである。読者が辿れる公開証拠へのリンクではない。source ledgerは非公開で保持し、本稿では原ログ、private repositoryのURL、内部path、session ID、未承認の画像を掲載していない。公開の一般資料へのリンクは測定方法の説明を支え、このプロジェクトの成功を独立に証明するものではない。
| ID | 非公開sourceの種類と対象 |
|---|---|
| E1 | 10月18日のrole routing調査記録。dispatchとruntimeの区別、UI確認の限界 |
| E2 | Parent中断を記録したIssue本文と復旧・通知の段階別Issue記録、復旧runbook |
| E3 | UI local validation追記。正式比較はHOLD、局所観測のみ |
| E4 | C9 method/authority記録、計測reportと最終独立reviewの受理記録 |
| E5 | MVPのCI・ローカル検証・独立最終review・merge記録 |
| E6 | 本稿準備時のremote main SHAのread-only照合 |
本稿そのものも2026年10月20日に、非公開の編集候補として独立した正確性・privacy・securityレビューを受けた。これはMVPのreviewとは別の確認であり、公開の許可ではない。公開とdeployは別途承認まで保留する。