7月のAI engineering build logには、公開リリース、管理されたテスト、内部ビルド、そして意図的な未リリースが含まれています。重要なのは、それらの境界です。ソフトウェアが1つの明確な状態を順番に通過していくことは、ほとんどないからです。
このログでは、ユーザーに届いたもの、TestFlight内にとどまったもの、シミュレーターまたはdebug buildでのみ検証したもの、そしてブロックされたままのものを扱います。私は「出荷済み」という言葉を狭く使っています。ローカルビルドは公開ではありません。テストの成功は採用ではありません。公開リストへの掲載は収益ではありません。何も送信しない承認ゲートが、正しいproduction結果になることもあります。
この月を支えた実践的なルールは、リリース規律でした。状態を定義し、外部からアーティファクトを検証し、機能が失敗したときの影響範囲を小さく保つことです。
2026年7月のAI engineering build log概要
| 結果 | 状態 | 証拠 | 教訓 |
|---|---|---|---|
| --- | --- | --- | --- |
| Memento Capture 2.3.7 | 公開 | 署名・公証済みDMG、同期済みのmanifestとサイト、新規ダウンロードによる検証 | ユーザーが受け取るアーティファクトを検証する |
| Mix Analyzerのキー検出 | 稼働中 | 既知のキーを持つ24個の管理された進行でmajor/minor検出を確認 | 都合のよい逸話より、管理された入力を優先する |
| Mix Analyzerのtoken recovery | 稼働中 | 解析失敗からの復旧が可視化され、owner単位で管理されている | 復旧はproduct contractに含める |
| Kiddaysのwaitlist | 稼働中 | double opt-in、英語・スウェーデン語のroute、canonical、sitemap | 同意と発見可能性は一緒に出荷する |
| Kiddays Premium build 74 | 内部TestFlight | 166テストを含む内部ビルド。購入、restore、trial-expiry、App Reviewは保留中 | テスト数が示すのは検証努力であり、リリースの影響ではない |
| 内部CRMのlead list | 稼働中 | モバイル検証済みのリスト、検索、5つのquick filterを備えたupgrade-safeな実装 | 管理ツールにもリリース規律が必要 |
| 2つのApify SEO Actors | 公開 | scoring Actorとrewriting Actorが空入力を拒否 | 公開されていることは収益化ではない |
| BroTider onboarding build 27 | 内部限定TestFlight | シミュレーターで検証済みのonboarding build | 内部配布はApp Store launchではない |
| FactCheck、outreach、Frame Insight | ブロック中またはdebug-only | FactCheckはlaunchせず、outreachは送信せず、Frame Insightはdebugの背後に維持 | 正直な未リリース状態が誤った主張を防ぐ |
Memento Capture 2.3.7は公開リリースの経路を通過する必要があった
Memento Capture 2.3.7を、署名・公証済みのDMGとしてリリースしました。ただし、この説明が意味を持つようになったのは、リリース経路の残りの部分も一致してからです。update manifestとWebサイトを同期し、その後、新規ダウンロードを実行して結果を検証しました。
ローカルアーカイブが正しくても、公開サイトが古いファイルを配信していたり、manifestが別の場所を指していたりする可能性があります。リリースとは、私のマシン上にあるファイルではなく、訪問者がMemento Capture download pageからダウンロードできるアーティファクトです。ダウンロードしたbuildにフォローアップが必要な場合の公開窓口は、Memento Capture support pageです。
この原則は、Webサイトをagentから呼び出せるようにする場合にも当てはまります。API responseやbuildの成功だけでは不十分です。公開状態が意図した状態と一致していなければなりません。そのアプローチについては、agent-ready websiteの構築方法→で説明しました。
Mix Analyzerは管理された証拠と可視化された復旧によって改善した
キー検出:まずは管理された証拠から
Mix Analyzerのキー検出に関する作業は、主張を大きく見せすぎやすいものでした。そのため、主張を限定しました。事前にキーが分かっている24個の管理された進行を使って、major/minor検出をテストしました。これにより、再現可能な入力セットと、明確な期待値を得られました。
24個の進行だけで、普遍的な精度が証明されるわけではありません。すべての録音、借用和音、転調、制作スタイルを網羅しているわけでもありません。1つの管理されたセットの下で、正しい方向に進んでいることを検証したものです。手法と限界については、major/minor key detection updateに記録しており、リリース状態はMix Analyzer changelogに掲載しています。
元の2曲はファイルが利用できなかったため、再テストできませんでした。自信のある再構成で置き換えるのではなく、その空白を見える状態にしておきます。入力を再現できないなら、以前のケースを新しい証拠に変えることはできません。
解析失敗からの復旧:可視化し、owner単位で管理する
この月には、失敗した解析のためのlive recovery pathも含まれていました。token recoveryが可視化され、owner単位で管理されるようになったため、復旧状態を確認でき、正しいアカウントに紐づけたまま維持できます。
私のルールは、実行前に期待する結果を定義し、管理された成功とproduction上の主張を分けることです。この枠組みは、実際の作業でAIモデルをベンチマークする方法→で使っており、audio analysisにも同じように適用できます。
Kiddaysは公開waitlistを出荷し、Premiumは内部にとどまった
Waitlist:公開
Kiddaysには7月、2つのリリース状態がありました。waitlistは、double opt-in、英語・スウェーデン語のroute、正しいcanonical、sitemapへの掲載を備えて公開されました。同意、配信、ローカライズ、検索による発見可能性が一致している必要がありました。
double opt-inにより、誰かが入力しただけのメールアドレスが、本人の意図にかかわらずアクティブなsubscriptionになることを防げます。canonicalはローカライズされたページ同士の関係を定義し、sitemapはそれらを発見可能にします。この種のリリースの背景にあるsecure beta waitlist pattern→については、別途執筆しています。
Premium:内部TestFlight
Kiddays Premiumは同じ状態には到達しませんでした。build 74は内部TestFlightで利用可能で、166テストのsuiteを備えていました。購入、restoreの挙動、trial expiry、App Reviewは保留中でした。App Store release、完成したsubscription system、またはcustomer outcomeとは呼びません。
166という数字が示すのは、検証範囲です。Premiumを何人が使うか、購入フローがreviewを通過するか、プロダクトが価値を生み出すかは示していません。テストは、既知の挙動が維持されていることを示せます。しかし、distribution、review、real useの代わりにはなりません。
より静かなリリースも日々の運用を変えた
内部CRM:稼働中だが非公開
名前を明かしていない内部CRMに、lead-listの改善を出荷しました。liveの結果はモバイルで検証済みで、検索と5つのquick filterを含んでいました。後から上書きされる可能性のある脆弱なcore surfaceの編集に依存しないよう、実装はupgrade-safeに保ちました。
これは公開product launchではなく、customer contextも非公開のままです。それでも、内部admin softwareにはcustomer-facing pageと同じ配慮が必要です。スタッフがdesktopとphoneの両方を使うなら、desktopでは動くがphoneでは失敗するリストは未完成です。
Apify Actors:公開、ただしmonetizedではない
また、最初の2つのSEO ActorsをApifyで公開しました。1つはarticle SEOをscoringし、もう1つはrewritingを支援します。どちらも、役に立つ結果を生み出せないリクエストにリソースを使わないよう、空入力を拒否します。公開とは、人々がActorを見つけられるということです。収益を生み出した、採用を獲得した、または市場を証明したという意味ではありません。
BroTider:内部限定
BroTider onboarding build 27は、別の限定された状態に到達しました。シミュレーターで検証され、INTERNAL_ONLYのTestFlight pathを通じて配布されました。App Store releaseではありません。シミュレーターでの検証から得られたのは、その環境におけるonboardingについての証拠であり、すべてのdeviceでの挙動や公開準備が整ったことではありません。
3つのものは出荷されなかった。それも作業の一部だった
FactCheckはブロックされたままでした。未解決のlaunch stateをrelease announcementに変えることはしませんでした。
outreach workflowは、承認ゲートが停止させたため、何も送信しませんでした。これは意図した挙動です。recipientのdraft作成や準備は、外部メッセージの送信を許可するものではありません。重大なアクションの前に停止するシステムは、送信数が0件でも有用です。deterministic AI agent permissions→についての記事で原則を説明しています。modelはアクションを提案できますが、それを実行するかどうかはpolicyとownerが決めます。
Memento Frame Insightはdebug-onlyのままでした。debug outputは、pathが実行されることを証明し、誤った前提を明らかにできます。しかし、それはuser-facing featureでも、supported workflowでも、featureが変更されずに出荷されるという約束でもありません。
月次ログには、こうした未リリースも残したいと考えています。それらを削除すれば、月はよりきれいに見えるかもしれませんが、engineering recordとしての有用性は下がります。
7月に出荷方法について変わったこと
この月から、4つのルールが生まれました。
最後のルールは、trajectory-level sandbox controls→についての考え方にも影響しています。長時間動作するautomationには、個別には合理的なcontrolの弱い組み合わせを見つける機会が何度もあります。scopeを小さくし、独立した検証を行うことで、そのリスクを下げられます。
Build数とtest数は、何を確認したかを示すため、ここに記載しています。これらはimpact metricsではありません。commit countはrepository activityを測定します。test countは定義されたsuiteを測定します。build numberはアーティファクトを識別します。別の証拠がなければ、どれもadoption、satisfaction、revenue、user valueを示しません。
Evidence and review note
このdraftを保存する前に、公開されているMementoのdownload pageとsupport page、Mix Analyzerのchangelogとproduct update、そしてApify profileを確認しました。内部TestFlight、blocked、debug-onlyの項目は、その状態のままラベル付けしています。これらのsourceはrelease stateを確立しますが、adoptionやrevenueを証明するものではありません。
8月に持ち越すもの
8月は、新しいpromiseのリストではなく、未完成の境界から始まります。Kiddays Premiumは、publicly releasedと説明できるようになる前に、purchase、restore、trial-expiry、App Reviewの作業がまだ必要です。BroTiderは、App Store claimを行う前に、シミュレーター検証と内部TestFlightを超える証拠が必要です。FactCheckは、launch conditionが変わるまでブロックされたままです。Frame Insightは、debug-onlyの状態を離れるまでexperimentのままです。
Mix Analyzerについては、管理されたkey setが現在持っている証拠です。利用できない2つの元の曲は、入力が再び利用可能にならない限り、明示的なgapとして残ります。
今後も同じreporting ruleを守ります。何が変わったかを述べ、手元にある最も強い証拠を添え、裏付けのない結果は空欄のままにします。似たようなAI、app、automation systemを構築しているなら、ぜひフォローするか、最も困っているrelease boundaryについてメッセージを送ってください。
