Blacksmith Series C、AIコードがテストを圧迫する中でユニコーン企業に
Blacksmithは10月21日、Sequoia Capital主導で6,600万ドルのSeries Cを実施し、評価額10億ドルに達したと発表した。Blacksmith Series Cは、特定の前提を支えるものだ。AIによってより多くのソフトウェアを生み出す企業には、そのソフトウェアを検証するためのインフラもより多く必要になる。継続的インテグレーション（CI）は、チームが変更をメインのコードベースに統合する前に、コード変更を自動でビルド・テストする仕組みである。Blacksmithは、顧客がより多くの変更を生成するなかで、その業務を引き受けようとしている。
差し迫った課題は、自ら管理するインフラを拡張するか、その責任を専門事業者に委ねるかを決めるエンジニアリングチームにある。GitHubのワークフロー自動化サービスであるGitHub Actionsは、チームがチェックを実行するマシンを選べるため、身近な比較対象となる。Blacksmithの機会は、コード生成をめぐる競争ではなく、そのインフラ選定の中にある。
今回の資金調達は、事業拡大に対する投資家の支持を示すものだ。ただし、より高速なチェックがより安全なソフトウェアを生むことや、追加のチェックがすべて有益な作業であることを証明するものではない。この区別は、発表を評価する買い手にとって重要である。中心的な問いは、専門的なCIインフラが、増大する計算需要を、提案された変更から承認済みソフトウェアに至るまでの、より短く信頼性の高い経路へ転換できるかどうかだ。
Blacksmith Series C、資金調達の節目を超える拡大を後押し
新たな資金調達により、Blacksmithはコードテスト事業を支えるインフラ拡張のための資本を得る。
BlacksmithのSeries C資金調達には、Premji Investに加え、既存投資家のPeak XV Partners、GV、Y Combinatorが参加している。同社によると、累計調達額は1億2,500万ドルに達した。チームとコンピューティング能力を拡大する計画だ。
こうした詳細から、このニュースはベンチャー資金調達の話であると同時に、インフラ拡張の話でもある。顧客のビルドを実行するサービスには、実際の実行能力が必要となる。採用もその取り組みを支えるが、サーバー、データセンターの手配、利用可能なマシンに作業を割り当てるソフトウェアも同様に重要だ。
評価額は投資取引の条件を反映するものである。顧客のコスト削減、ソフトウェアの信頼性、あるいは事業の収益性を示す指標として読むべきではない。それぞれには別個の証拠が必要となる。
顧客にとって、新たな資本の実務的な意味合いはより限定的だ。Blacksmithが拡大計画を進めるための追加リソースを与える。買い手は依然として、サービス性能、契約上の約束、自社ワークロードに対するインフラの適合性を検討する必要がある。
Blacksmith Series Cはまた、エンジニアリングリーダーに既存の所有・運用判断を見直す理由を与える。ビルドを社内で実行すれば制御を得られるが、その制御には継続的な運用責任が伴う。実行を外部委託すれば、その責任を誰が負うかが変わる。
この判断が、単一テストの速度だけで決まることはほとんどない。チームは、作業開始までの待ち時間、障害の調査方法、インフラが利用不能になった際の対応者にも関心を持つ。高速なマシンが解決できるのは、全体的な体験の一部にすぎない。
投資発表だけで、こうした疑問に答えることはできない。しかし、その答えを示そうとするサプライヤーが利用できるリソースは変えられる。Blacksmithは、顧客のソフトウェアデリバリーシステムのより大きな部分を担う取り組みを支える資本を、これまで以上に得た。
Sequoiaなどの投資家にとって、参加はその拡大への支持を示す。ただし、彼らの関与がサービスの独立したベンチマークを提供するわけではない。投資判断と運用面での検証は、依然として異なる種類の証拠である。
したがって、重要な変化は具体的だ。Blacksmithは、ビルドとテストを実行する事業に向けた追加資金を確保した。この拡大が顧客のデリバリーを改善するかどうかは、資金調達発表の後に何が起きるかにかかっている。
生成コードの増加がインフラ所有者に圧力
既存システムが評価できる速度を上回って変更提案が到着する場合、インフラに関する判断はより緊急性を増す。
BlacksmithのCIワークロード成長に関する数値は、その拡大ストーリーを支える最も明確な証拠となる。同社によると、週次のCIジョブ数は1月の500万件から9,000万件超へ増加した。ジョブとは、自動化されたワークフロー内で実行される個別の作業単位である。
この週次指標は重要だ。企業の歴史を通じて蓄積された累計ではなく、継続中の活動を示している。ただし、これはジョブの複雑さや顧客分布について独立検証された内訳を伴わない、同社報告の数値でもある。
Blacksmithは、継続収益を年換算した指標である年間経常収益が、同期間に17倍へ増加したとしている。また、1万社超にサービスを提供しているとも報告している。顧客としてMercury、Granola、Handshake、LangChainを挙げている。
これらの開示は合わせて、導入とワークロード量が拡大しているという主張を裏付ける。ただし、活動のどの程度が既存顧客、新規顧客、あるいはワークフロー上の作業分割の変化によるものかは明らかにしていない。こうした区別は、読者が成長をどう解釈するかに影響する。
コードを提案・変更できるソフトウェアシステムであるAIコーディングエージェントを使うチームの運用状況を考えてみよう。エージェントが変更を提出し、自動チェックが実行され、結果を受け取ったエージェントが提案を修正する。各反復によって、人間が何かを承認する前の実行作業が増える可能性がある。
これは特定のBlacksmith顧客について検証された説明ではなく、例示的なワークフローである。その意義はフィードバックループにある。生成が高速化すると迅速なフィードバックの価値が高まる一方、チェックの遅延はそのループを中断する。
この圧力はまず、実行環境を所有する者に及ぶ。共有の開発者インフラを担当するプラットフォームエンジニアリングチームかもしれない。製品業務と並行して独自の自動化を保守するアプリケーションエンジニアの場合もある。
こうしたチームは競合する要求に直面する。作業が到着したときには十分な能力が必要だが、遊休状態のリソースを維持することも避けなければならない。提案コードの本当の欠陥と混同せずに、インフラ障害を調査する必要もある。
計算能力を増やしても、問題が自動的に解決するわけではない。一部のテストは、他のテストが先に完了することに依存する。外部サービスが原因となる障害もある。ソフトウェアに対応する変更がないまま成功・失敗する、信頼性の低いテストによるものもある。
このため、事業機会は「AIがより多くのコードを生む」という以上に具体的になる。Blacksmithには、専門事業者を選ぶことを正当化できるほど実行上の問題が大きい顧客が必要だ。最も強い需要は、インフラ改善を測定可能なデリバリー成果に結び付けられるチームから生じるはずだ。
そのためエンジニアリングの買い手は、ジョブ成長を活動の証拠として読むべきである。価値を確立するには、その活動と、変更について有用な判断に達するまでに必要な時間との、さらなる結び付きが必要となる。
専門CIは、チームがすでに制御するインフラと競合する
Blacksmithにとっての中心的な競争課題は、専門的な実行環境を委任する価値があるとチームに納得させることだ。
関連する代替手段は、単に別のスタートアップではない。権限、運用手順、社内の所有責任を含む、顧客がすでに理解しているインフラ構成である。その構成の一部を置き換えるには、デモを超えて通用する理由が必要となる。
GitHubのself-hosted runnersに関するドキュメントは、このトレードオフを示している。runnerとは、ワークフロージョブを実行するマシンまたは環境である。自らrunnerを管理するチームはハードウェアとソフトウェアをカスタマイズできるが、保守責任も負うことになる。
これは社内インフラに、制御という持続的な利点を与える。チームは実行環境を非公開システムの近くに配置し、専用の依存関係を導入し、特殊な要件に合わせて環境を適応させられる。こうした選択は、一般的なワークロードでの性能以上に重要になる場合がある。
その一方で、運用作業という負担が生じる。誰かが環境を保守し、障害を調査し、十分な能力が確保されていることを担保しなければならない。こうした責任が、本来は別の用途に向けるべき注意力を消費している場合、専門サプライヤーに機会が生まれる。
競争の境界は、Blacksmith対GitHubよりも複雑だ。ワークフローの調整とジョブの実行は別の機能である。チームは使い慣れたワークフロー定義を維持しながら、作業を担うマシンを再検討できる。
この区別は、購買判断を狭める。顧客は、実行インフラを変更するために開発プロセス全体を置き換える必要があるとは限らない。ただし、新しい構成が、依存している挙動と制御を維持することは検証する必要がある。
Buildkiteも有用な比較対象となる。そのドキュメントは、適切な作業を複数の実行ジョブに分割する並列テスト実行を説明している。このアプローチは、ビルド性能がハードウェアだけでなく、ワークロードの組織化にも関わる理由を示している。
この比較によって、プロバイダー間の勝者が決まるわけではない。顧客には遅延に対処する方法が複数あることを示している。実行インフラを変更することも、テストを再編成することも、インフラ変更とワークフロー改善を組み合わせることもできる。
Blacksmithにとって、これは「より多くの能力」が出発点の提案であることを意味する。説得力ある顧客事例では、どの遅延要因が変化し、その理由は何かを説明すべきだ。待機時間の短縮、実行の高速化、運用上の中断の減少は、それぞれ異なる成果である。
比較では、同等の作業を維持する必要もある。試験運用でチェック数を減らしたり、重要な依存関係を省いたりすれば、より短い完了時間の解釈は難しくなる。買い手は、同じ判断が同じ水準の精査を受けたかを知る必要がある。
社内チームには、ベンチマーク結果には現れない知識もある。特殊なビルド依存関係、繰り返し起こる障害パターン、設定選択の歴史的な理由を理解している。移行では、その文脈へのアクセスを維持するか、理解可能なドキュメントで代替しなければならない。
ここに、専門CIインフラが直面する最も実務的な試練がある。責任移転を正当化できるだけの運用価値を提供しなければならない。顧客は、サプライヤーの資金調達や評価額に頼らず、自らの言葉でその価値を説明できるべきだ。
最も強い競争上の立場は、既存のエンジニアリング慣行の中で一貫して有用な存在になることから生まれる。これには、信頼できる実行、理解可能な障害、顧客がより運用しやすいと感じる所有モデルが必要となる。
より速いフィードバックが、コード改訂ごとの経済性を変える
この機会を支える仕組みは、変更の提案からチェックを通過するかの判明までのフィードバックループを短縮することにある。
ソフトウェアデリバリーは判断に依存する。開発者またはエージェントが何かを提案し、証拠を受け取り、次に何を変更するかを決める。インフラは、その証拠が利用可能になるまでの速度に影響する。
待機時間は、個々のテストが比較的速く実行される場合でも積み上がる可能性がある。ジョブは実行開始前に、利用可能なマシンを待つことがある。後続のステージは、先行する作業の完了を待つ場合がある。インフラ障害によって、チームがプロセスの一部をやり直さざるを得なくなることもある。
これらは異なる制約であり、それぞれ有効な対策も異なる。作業がマシン待ちの場合は、追加のキャパシティが役立つ可能性がある。適切な実行タスクでは、より高速なプロセッサが有効になり得る。ワークフロー自体が進行を制約している場合は、依存関係の再編成が助けになる。
この違いは、顧客固有の証拠が重要である理由を示している。サプライヤーはコンポーネントを改善できても、全体のデリバリー経路を改善できるとは限らない。購入者は、有用な回答が得られるタイミングを左右するステップを特定する必要がある。
この影響は、エージェントがテスト結果を使ってコードを修正する場合に特に重要になる。フィードバックが遅れると、次の修正が待機状態になる。迅速なフィードバックがあれば、元のコンテキストが利用可能な間に、システムや開発者は作業を継続できる。
とはいえ、回答が速くても、正しい問いに答えていなければ価値は限定的だ。ビルドの成功は、特定の一連の操作が完了したことを示す。しかし、提案された機能がすべてのユーザー要件を満たすことまでは示さない。
Blacksmith Series Cは実行インフラの拡張を支えるが、そのインフラが何を評価するかは顧客が決める。テスト設計、レビュー慣行、リリース基準が、結果の意味を形作る。
したがって、このサービスを評価するエンジニアリングチームは、実行効率と意思決定の質を分けて考えるべきだ。前者はチェックをどれだけ効率的に実行できるかに関わる。後者は、そのチェックが変更を承認するのに十分な証拠を提供するかに関わる。
両方が同時に改善する可能性はあるが、どちらももう一方を保証しない。チームは結果を早く受け取れるようになっても、重要な障害条件を対象としたテストが不足している場合がある。また、テストが十分に整備されていても、実行に時間がかかりすぎて使いにくいこともある。
最も有用な成果は、適時の結果と意味のあるチェックを組み合わせることだ。それにより、レビュー担当者は対応する機会が残っているうちに証拠を得られる。欠陥とインフラ上の問題を区別することも容易になる。
明確な記録はこのプロセスを支える。チームは、テストカバレッジ、例外、移行時の前提、障害の責任範囲に関する判断を残す必要がある。検索可能なナレッジベースは、技術文書と併せてこうした説明を保持するのに役立つ。
ナレッジの記録は、実行インフラとは異なる役割を果たす。その重要性は、チームがあるチェックが存在する理由や、例外が承認された理由を理解する必要があるときに現れる。実行が高速化しても、コンテキストの必要性はなくならない。
そのため購入者にとって、この仕組みは単純化しすぎることなく測定可能だ。問うべきなのは、インフラの変更が信頼できるエンジニアリング上の判断に到達するまでの時間を短縮するかどうかである。完了したジョブ数だけでは、その答えは得られない。
ジョブの増加はソフトウェア品質や持続的な経済性を示すものではない
Blacksmithが報告した成長は需要拡大の物語を支える一方、重要な技術面・商業面の疑問は残している。
最初の不確実性は、何を単位として数えているかにある。CIジョブは、実行時間、必要なリソース、目的が大きく異なり得る。小規模なチェックを実行するジョブは、大規模なアプリケーションをコンパイルしてテストするジョブと同等ではない。
ワークフロー設計もジョブ総数に影響する。既存の作業をより多くのジョブに分割すれば、有用な出力が同等に増えなくても件数は増える。失敗した作業を繰り返すことは活動量を生むが、必ずしも変更を承認に近づけるわけではない。
こうした点は、Blacksmithの数値に問題があることを示すものではない。ボリューム指標にはコンテキストが必要である理由を説明している。読者は、追加されたすべてのジョブを、追加で完成した機能や防止された欠陥と見なすべきではない。
収益開示にも同様の限界がある。成長倍率は、以前のベースラインに対する変化を表す。詳細な財務内訳がなければ、収益性、顧客集中度、追加ワークロードの提供コストまでは示さない。
インフラ事業は、可用性と利用率、すなわち利用可能なリソースのうち顧客が実際に使用する割合とのバランスも取らなければならない。余剰キャパシティを維持すれば、応答性を支えられる可能性がある。一方で、顧客需要が顕在化する前にコストを生むこともある。
Blacksmithは、米国と欧州のデータセンター全体で、10メガワット弱のコンピューティング能力を管理していると述べている。メガワットは電力を測る単位であり、この数値は同社が説明する物理的規模を示す。Blacksmithは2027年にこの基盤を5倍に拡大することを目指すとしている。
こうした開示から、キャパシティ拡張の実行状況は注視に値する。ただし、運用効率を算出するには十分な情報ではない。読者には、実際の消費量、利用可能なキャパシティ、ワークロードのパターン、インフラコストに関する詳細がさらに必要となる。
セキュリティは別の制約をもたらす。CI環境はコードを実行し、多くの場合、認証情報や内部システムと連携する。スループットを高めても、そうしたやり取りを制御する必要性はなくならない。
OWASPのrunner securityに関するガイダンスは、ネットワークや保存済みシークレットへのアクセスを含め、セルフホスト型実行環境に伴うリスクを指摘している。これはBlacksmithに関する評価ではなく、一般的なセキュリティガイダンスである。
エンタープライズの購入者にとって、その意味するところは実際のサービス境界を確認することにある。関連する問いには、ワークロードをどのように分離するか、認証情報をどう扱うか、実行環境を利用ごとにどうクリーンアップするかが含まれる。回答は文書化された統制から得るべきだ。
信頼に関する表現にも限界がある。テストの合格は、特定の条件下で実行されたチェックをソフトウェアが満たしたことを意味する。未テストの欠陥、安全性を欠く前提、誤解された要件が存在しないことまでは示さない。
したがって、懐疑的な読み方は具体的だ。Blacksmithは需要拡大と整合する指標を開示しており、投資家はさらなる拡張に資金を提供している。独立した顧客成果と、より充実した運用開示があれば、これらの発表を超えて根拠を強められるだろう。
この基準は分析を現実に即したものに保つ。報告された成長を否定することもなければ、利用可能な証拠が裏付けられない主張へと変換することもない。
キャパシティの提供、顧客成果、既存事業者の対応を注視する
次に必要な証拠は、拡張が実行可能な運用モデルを維持しながら顧客成果を改善するかどうかを示すはずだ。
今後数カ月で、最初に注視すべきシグナルはキャパシティの提供だ。Blacksmithが示した拡張計画は方向性を示すが、購入者には追加インフラが自社ワークロードに必要な場所で利用可能になる証拠が必要である。
有用な更新情報は、新しいキャパシティをサービス挙動と結び付けるものだ。可用性、待機時間、繁忙期のパフォーマンスは、拡張の発表だけよりも多くを教えてくれる。一貫した提供が確認されれば、実行を専門事業者に委ねる根拠は強まる。
第二のシグナルは、詳細な顧客証拠である。Blacksmithの以前の資金調達発表と現在の開示は顧客導入を示している。次に有用なのは、顧客のエンジニアリングプロセス内で何が変わったかを説明する事例だろう。
説得力のある例では、当初の制約、実施した作業、デリバリーにもたらされた変化を説明する。待機時間の短縮と実行速度の向上を区別する。また、チームが同等のチェックを維持したかどうかも説明する。
通常の作業と繁忙期の両方を対象とした証拠は、特に価値が高い。需要が集中する状況で苦戦しながら、余裕のある条件では良好に機能するサービスもあり得る。顧客は、報告された改善の背景となる条件を理解する必要がある。
より弱いシグナルは、その作業内容に関する情報を伴わない、別の見出し用のジョブ数だ。ボリュームは依然として重要だが、顧客成果があればその意味を評価しやすくなる。同じことは、付随するコンテキストのない成長主張にも当てはまる。
第三のシグナルは、既存プラットフォームと社内インフラの所有者による対応だ。より優れたマネージド実行、容易なキャパシティ拡張、改善されたワークフローツールは、顧客に追加の選択肢を与える。こうした進展は、Blacksmithが勝ち取る必要がある比較をより明確にするだろう。
既存事業者の改善が、専門事業者への需要を自動的に消すわけではない。ただし、差別化の基準は高まる。Blacksmithは、代替手段でも対応できるワークロードに対して、自社の実行モデルがなぜ依然として有用なのかを示す必要がある。
社内チームも、自らの判断を通じて対応する。一部は実行をさらに委任する。別のチームは、自らの要件からその体制が望ましいとして管理を維持する。重要な証拠は、実務的な評価後にこうした意思決定がどのように変化するかである。
これらのシグナルは一体として捉えるべきだ。キャパシティは拡張を可能にし、顧客成果は価値を示し、競合の対応はその価値がどれほど独自性を保つかを決める。資金調達だけを追っていては、それらを結び付ける運用上の問いを見落とすことになる。
エンジニアリングリーダーは、まずチームがすでに観測できる遅延から始めるべきだ。作業がマシンを待っているのか、実行が遅いのか、予測不能に失敗するのか、十分な裏付けなしにレビュー担当者へ届いているのかを特定する。同等のチェックと文書化された条件を用いて、その制約に照らして代替案を比較する。移行時の前提、責任範囲の変更、未解決の問いを記録し、後の結果を解釈可能な状態に保つ。Blacksmith Series Cは同社に拡張のための資源を与えるが、判断は自社のデリバリープロセスの挙動に従うべきである。インフラを変更する前に、提案されたコードから承認済みソフトウェアに至る経路のどの部分を改善すべきか、そしてその改善をどのような証拠が示すのかを問うべきだ。
