ハーネスエンジニアリング｜70人が15人になって分かったこと

UXデザインやソフトウェア開発の会社が「自分たちだけができる」という顔で語っていることは、実はもう、誰にでもできることになっている。

ARCHECOを知らない方のために、簡単に自己紹介をさせてください。僕は2014年にARCHECOを創業し、この12年間、UXデザインと、アプリやWeb、業務システムといったソフトウェアの開発に携わってきました。

その僕が今、UXデザインとソフトウェア開発の産業は終わったと確信しています。それを記事にすることには、とても抵抗がありました。それでも、あえて書くことにしました。

70人の会社が、15人になった

書こうと思ったきっかけは、バングラデシュに設立したShellBeeHakenという会社で、大規模なリストラを行ったことです。

昨年まで、ShellBeeHakenにはグループ会社も含めて70人の従業員がいました。それでも僕たちは、いつも深刻な人手不足に直面していました。現地の共同設立者でありCEOは、人を採用し、育てることに死力を尽くしてきました。その育成には、僕も少なからず携わってきました。

この会社を共同で設立する前、僕は開発会社に対して、いつも同じストレスを感じていました。

「仕様に書かれていないので、やっていません。要求から漏れていたので、こちらの責任ではありません。追加見積もりになります。」

僕はこのやり取りを、根本から変えたいと思っていました。仕様から多少漏れていても、要求が途中で変わっても、意図がうまく伝わらなくても、現場のエンジニアが自分のプロダクトだというオーナーシップを持つ。より良い仕様や機能を思いついたら、相談するか、両方を試してみる。その追加の検討や実装に、いちいち追加の見積もりを出さなくてよい。そんな組織を目指して、この会社を作りました。

「プロジェクトとしていくら売り上げたかではなく、いかに良いプロダクトを作るかで評価する。」

僕たちはこの理念を、会社のホームページに大きく掲げました。そして、理念を絵に描いた餅にしないために、価格を工夫しました。現地の人件費と物価の安さを生かし、何度でもやり直し、積極的に提案できるだけの余裕を持った単価にしました。それでいて、クライアントにとっても十分リーズナブルな価格にしました。

ShellBeeHakenのホームページに掲げた理念のスライド（Project と Product の対比）

正直に言えば、理念を掲げるだけなら、どの会社にもできます。耳ざわりの良い言葉を並べれば、表面上はどこも同じことを言っているように見えます。けれど、理念を本当に実行できる状態にすること、そして社員がその理念を本気で信じて行動することは、まったく別の成果を生みます。外からは、よくある「自分ごと化」を掲げる会社に見える。でも中では、本当に”自分ごと”として動いている。その差はすぐには伝わらなくても、長い目で見れば必ず伝わる。僕はそう信じて、この会社に関わってきました。

技術の面でも、勝てるという確信がありました。バングラデシュの人たちは勤勉で、国としてもすでに、アメリカのテック企業にとってインドに次ぐオフショア開発の発注先になっています。サイバー攻撃への対策をはじめとするセキュリティに高い水準で応えられる人材も豊富です。僕たちの会社も、日本の第三者機関による金融レベルのセキュリティ審査で、毎回満点を取ってきました。使い勝手を損なう一部の項目は、意図して緩めていましたが、意図しない問題は事前にすべて潰せていました。技術力が高く、仕事への姿勢も一流で、価格でも勝てる。だから必ず勝てる。そう思って、僕たちはこの会社を6年前に立ち上げました。

もちろん、組織づくりは一筋縄ではいきませんでした。最初のころは、「この要件は自分では判断できないので進められない」「クライアントからの情報を待っているので進められない」という言葉が飛び交っていました。

僕は、この体質を変えることを何より重視していました。プロジェクトが始まるたびにバングラデシュへ行き、「このチームで禁止することは一つだけ、”待つ”ことだ。一度でも待った人は、プロジェクトから外す」と伝えました。UXデザインの教科書も作り、何度も研修をして、要件が書かれていなくても、ユーザーのために何を作るべきかを自分で考える習慣を根付かせました。

そんな熱湯風呂のような環境で、同じ釜の飯を食べるうちに、僕たちは家族のようになっていきました。

その会社を、僕は今、縮小し、解体する方向へ舵を切っています。年末には、70人いたメンバーは15人ほどになります。

この6か月、毎日、体をちぎられるような思いでした。それを現地で実行している共同設立者に、かける言葉も見つかりません。

それでも、この決断に至った理由はとてもシンプルです。AIでやった方が、良いものを速く作れるようになったからです。そしてそれは、この先何があっても覆りません。

「専門家だからAIを使いこなせる」は本当か

僕たちがどれだけ頑張っても、LLMそのものを開発して賢くすることはできません。これはどの会社も同じ条件です。今からAnthropicやOpenAIに勝てる可能性は、ゼロです。

だから、どの会社にも残されているのは、その頭脳を使いこなす技術を高めることだけです。

ところが、多くのデザイン会社や開発会社は、こう訴えて仕事を取りにいっています。「UXデザイン会社だから、デザインの自動化ができる」「開発会社だから、ハーネスエンジニアリングができる」。

僕は、この訴えを頭から否定します。

もしそれが専門家にしかできないことなら、僕はShellBeeHakenを縮小していません。AIを使いこなす専門性と、AIを使ってやりたいことの専門性は、まったく別のものです。

たとえば、UXデザイナーがUXデザインを自動化しようとすると、こう考えます。

コンセプト設計 → 体験設計 → 情報設計 → ガイドライン作成 → ワイヤーフレーム・画面遷移の設計 → グランドデザイン → 画面制作 → システム要件・仕様定義→システム開発

まずこの流れを前提に置き、それぞれの作業を順に自動化しようとします。ここに大きな落とし穴があります。人がやってきた手順を、AIにそのままなぞらせることになるからです。

AIを使うのが上手い人は、手順を自動化しません。代わりに、次のような仕組みを作ります。

AIが止まりにくい仕組み
AIが組織の考え方に沿って判断する仕組み

AIが使う道具を整え続ける仕組み
AIが自分で試し、確かめ、出来を磨き続ける仕組み

人がときどき軌道を直せる仕組み
AIのトークンやメモリの使い方を無駄なく保つ仕組み

そのうえで、やりたいことを雑に丸投げします。

つまり、人手でやっていた時は最後の工程だったシステム開発は、一番最初の工程に変化します。

なので、UXデザインやシステム開発の専門家が”人間”のワークフローを知っていることは何の強みにもなりません。

AIが出力する形式として得意なものを知ってその過程で重要なことを知っているひとの方が高い生産性と高品質なものを出力できるのです。

今から、それを証明します。

僕が打ち込んだのは、これだけです

たとえば、店やオフィスで流すBGM。USENのようなラジオを、AIだけでコスト0にできないか。10月24日の13時12分、僕はAIに次の一文を送りました。

「AI生成のみの音楽を扱うSpotifyはつくれるのか（USENの無償化）？（中略）実際にアプリを作りながら、その過程で躓いたり、上手くいかない過程があっても、それが完全に上手くいって完成して、全てトレースできたるところを目指して。余力があれば、TikTokも開発して。」

そのあと僕が打ったのは、「その都度あなたの判断で完全に決定して」という指示と、途中で方向がずれたときの「spotifyをそのまま作るのが重要。」、そして会議中に音が鳴ったときの「止めて」くらいです。画面の設計も、仕様書も、技術の選定も、何もしていません。

約10時間後、手元にはSpotifyと同じ構成のスマホアプリがありました。ホーム、検索、ライブラリの画面があり、全画面のプレイヤーで次に流す曲を並べ替えられます。プレイリストも作れ、オフラインでも聴けます。時間帯に合わせてチャンネルが切り替わる店舗モードは、そのままUSENの代わりになります。曲はAIが作った60曲、146分。追加で払ったお金は0円です。開発の記録は、保存が52回、AIへの指示書が22本、日誌が547行、すべて残っています。一晩かけた8時間の連続再生テストでは、曲が205回切り替わり、途中で朝の時間帯へのチャンネル切り替えもはさみながら、止まった回数もエラーも0でした。iPhone版でも8時間で曲が196回切り替わり、止まった回数は0でした。途中でエラーと曲の重複が1回ずつ記録されましたが、AIが自分で調べたところ、どちらもアプリではなく記録する側の誤検知でした。

同じ日に、TikTokも並行して作らせました。約14時間半で、本家の公式ヘルプから拾った112の機能のうち103が、本家と同じ操作で動いています。ライブ配信も、ブラウザ同士をつなぐ形で数人まで動きました。作れなかったのは本当のお金と外部の身元確認が要る機能で、追加で払ったお金は0円です。

Spotifyと同じ構成で作らせた音楽アプリ。実際に操作した画面の録画（54秒・無音）

TikTokと同じ操作で作らせた短い動画のアプリ。実際に操作した画面の録画（45秒・無音）

僕はこのとき、UXデザインの技術も、システム開発の技術も、何ひとつ使っていません。使ったのは、僕たちが設計し、実装してきたハーネスだけです。この10時間、AIはその上で動いていました。

ただ、この記事で本当に伝えたいのは、この結果ではありません。

この10時間のあいだに、AIは何度もつまずきました。そして、そのつまずき方は、僕たちがこれまでAIを組織で使う中で、繰り返し見てきた課題とほとんど同じでした。ここからは、その課題が今回の10時間の中でも実際に現れた様子を、ひとつずつ書いていきます。課題は大きく2つに分かれます。AIの周りに付ける仕組みと、AIを使う人と組織の側の備えです。

AIの周りに付ける仕組み：ハーネス

ハーネスとは、もともと馬具のことです。馬がどれだけ力強くても、手綱や鞍や引き具がなければ、荷車は引けません。AIも同じです。モデルの賢さは力そのもので、ハーネスはその力を仕事に変える道具一式です。AIに渡す指示や文脈、AIが使える道具、与える権限、止まっても続きから動かす仕組み、記録、出来を確かめる仕組み。これらをまとめて設計して作ることを、ハーネスエンジニアリングと呼びます。

今回の2つのアプリを動かしていたのは、僕たちが設計し、実装したハーネスです。AIへの指示の渡し方、判断の型の読み込み、15分ごとの見回り、重い処理の順番の鍵、記録と検収の決まり。どれも既製品ではなく、僕たちが自分たちの運用の中で作り、直し続けてきたものです。その中で欠かせないと考えてきた部品は、7つあります。今回の10時間でも、そのすべてが実際の場面として現れました。

1. AIが組織のルールに沿って働く仕組み

開発を始めて3時間ほどたったころ、僕は担当のAIに「再生テストとか音源よりも、まずはアプリ作成。意図を理解していますか？」と打ちました。AIは「店のBGMとして流しっぱなしにする」という一文に引っぱられて、Webの音楽プレイヤーを磨き、曲を量産し、連続再生のテストを回していたのです。僕が見たかったのは、Spotifyそのものでした。AIは作業を止め、途中の変更を退避して、スマホアプリに作り直しました。

AIは賢いのに、意図を外します。外す原因の多くは、言葉の要約です。誰かが「店のBGMプレイヤー」と要約した瞬間に、「Spotifyを作る」という主語が消えてしまいました。

だから僕たちは以前から、AIへの指示書に僕の言葉を原文のまま貼っています。さらに、僕が過去にAIへ伝えてきた言葉から「判断の型」を抜き出して蓄え、AIが動き出すたびに自動で読み込ませています。「承認待ちのボトルネックにならず、合理的に判断して進める」「有料より無料枠を優先する」といったものです。今回の取り違えをすぐに直せたのも、原文が残っていたからでした。曲を作るモデルを選ぶときも、AIはこの型に沿って、重みが非商用に限られるMusicGenや、同意の手続きと年商の条件があるモデルを外し、商用で使えて手続きの要らないACE-Step 1.5を自分で選びました。

人の頭の中にあるルールは、AIにとっては存在しないのと同じです。組織の考え方と決まりを、AIが毎回読める形で置いておく。これが1つ目の部品です。

2. AIに渡す道具

今回は、音楽のアプリと短い動画のアプリを、2体のAIに並行して作らせていました。どちらもメモリを大量に使います。このMacのメモリは18GBしかなく、退避領域は最大で30GBまで膨らみました。するとAIは、最初に小さな道具を自作しました。重い処理の前に共有の鍵を取り、相手が使っている間は待ち、空きメモリが10%を切っても待つ。それ以来、2つのプロジェクトは一度もぶつかっていません。

メモリ18GBのMacでも、AIが自作した「共有の鍵」で、2体は一度もぶつからなかった

逆のことも、これまでに起きています。AIに渡していた道具の置き場所が、アプリの更新で消えてしまったのです。今は、毎回「いま本物がどこにあるか」を調べてから使う形に替えています。

AIの成果は、AIそのものより、AIが手に取れる道具で決まります。そして道具は、放っておくと壊れます。AIに渡す道具を作り、壊れたら直し続ける。これが2つ目です。

3. ガードレールの設計

確認のために起動したシミュレーターから、Macのスピーカーで曲が流れたことが2回ありました。2回目は、僕が会議に出ている最中でした。AIはどのプロセスが音を出しているかを突き止めて止め、「音量0で再生し、再生位置が進むかで確かめる」という決まりを、すべての指示書に書き足しました。

ところが、最初に音を止めたとき、AIは「codexの実行」という名前に合うプロセスを、まとめて終了させていました。もう1体のAIが同じ時刻に動いていれば、巻き込んでいたかもしれません。AIは自分でそれに気づき、「以後は自分の作業フォルダのプロセスだけを止める」と記録しています。別の日には、AIの確認画面に自動で答えを送ったところ、意図と違う選択肢が選ばれ、外部サービスの設定が1件、許可なく書き換わったこともありました。すぐに元に戻しましたが、ひやりとしました。

AIの事故は、悪意からではなく、善意と効率から起きます。「止めて」と言われれば、確実に止めようとして、広く止めてしまう。だから、やってよい範囲を先に決めておく必要があります。お金は払わない。公開する前には報告する。止めるのは自分のものだけ。AIに越えさせない線を、あらかじめ引いておく。これが3つ目です。

4. 止まらない仕組み

AIは、驚くほどよく止まります。利用枠が切れて止まることも、作業場のアプリが再起動して落ちることもあります。けれど、こうした故障の止まり方は、実は少数です。AIが止まる理由のほとんどは、分かれ道に立ったことです。

今回も、そうでした。動画のアプリの担当は、重い処理の順番をもう1体のAIと取り合い、3回続けて待ちきれずに手を止めて、「どう分け合えばいいか」を書き残しました。本家の画面の手本が足りなくなったときは、「公式の端末を用意してよいか」で止まりました。音楽のアプリの担当は、夜9時に「完成しました」と言いながら、4つの作業を「後回し」にして止まっていました。どれも、壊れたのではありません。次にどちらへ進むかを、誰かが決める必要があっただけです。

だから、止まらない仕組みの本当の中身は、起こすことではなく、決めることです。今は、1分ごとに動く小さなスケジューラーが、15分ごとに全員の画面を読みにいきます。止まっていれば、その分かれ道でどちらを選ぶかを決めて、先へ進めます。重い処理は1回30分までで、返したら15分は取り直さない。手本は公式の端末から撮り、出どころの分からないものは使わない。「後回し」は認めず、その夜のうちにやり切る。今回も、こうした判断を僕を待たずに下しています。

そして、その判断には基準があります。僕がこれまでAIに伝えてきた7,000を超える発言から、「承認待ちのボトルネックにならず、合理的に判断して進める」「有料より無料枠を優先する」といった判断の型を抜き出し、AIが動き出すたびに読み込ませています。今回下した判断も、音楽のアプリで10件、動画のアプリで19件、理由とともに記録に残りました。それがまた、次の判断の材料になります。

分かれ道でどちらを選ぶかは、会社によって違います。速さを取るのか、安全を取るのか。お金を払うのか、時間をかけるのか。その選択が積み重なったものが、その会社の個性です。止まるたびに下す判断を、組織の考え方に沿って積み重ねていく。それによって、AIの働き方そのものに会社の個性が映ります。これが4つ目です。

5. 安全な環境

今回、AIは試聴ページを合言葉で閉じました。合言葉そのものは手元の1つのファイルにだけ置き、変更の記録にも日誌にも残していません。配信は無料枠で動かしていますが、無料枠を使い切ったときは「守りを外して配る」のではなく「止まる」ように設定しました。AIはパスワードを一度も入力していませんし、それぞれのAIは自分の作業フォルダの外には書き込めません。別のAIへの引き継ぎメモが書けなかったときは、まとめ役のAIが間に入って届けました。

AIに強い権限を渡すほど、作業は速くなります。同時に、漏れたときの被害も大きくなります。けれど、速さと安全は、設定のしかた次第で両立できます。権限を絞り、秘密を記録に残さない場所を、最初から作っておく。これが5つ目です。

6. 成果物を検収する仕組み

夜の9時、AIは「報告書まで完成しました」と言ってきました。ところが読んでみると、曲を60曲までそろえること、8時間の連続再生、Webの点検の残り、店で流すための権利の確認の4つが「後回し」と書かれていました。まとめ役のAIがそこを差し戻し、その夜のうちに全部やらせています。

途中の日誌には「指示書7本とも1回で完了」と書かれていましたが、その後の作業では不具合が何度も出ました。曲の品質も、機械で点検すると60曲中54曲が「要確認」でした。そして人の耳では、まだ1曲も聴いていません。今の報告書はそれを正直に書いていますが、そこまで書かせるのにも、何度かのやり直しが要りました。

AIの「できました」は、「できた」ではありません。作る速さが上がった分だけ、確かめる側の力が足りなくなります。AIの自己申告をうのみにせず、事実と数字で、別の目が確かめる。これが6つ目です。

7. 初期の事故に備える仕組み

会議中に音が鳴ったとき、僕が「止めて」と打ってから数分で音は止まりました。止められたのは、AIが変更のたびに保存し、どう戻すかを書き残し、1時間ごとに状況を報告していたからです。外部サービスの設定が誤って書き換わったときも、変更前の状態が記録に残っていたので、同じ状態に戻せました。

導入したばかりのころの事故は、なくせません。なくせない以上、被害の大きさは、小さいうちに見つけて戻せるかどうかで決まります。どんな変更にも戻し方を付け、事故をすぐに見つけて戻せるようにしておく。これが7つ目です。

AIを使う人と組織の側の備え

ここまでの7つを整えても、AIだけでは越えられないものが残ります。社内の決まりが道具に追いついていないこと。人にしか許されない操作。AIを使う人の腕。ルールを育てる組織。そして、何を選ぶかの判断です。

8. ルールの壁を、外で安全に越える仕組み

今回の10時間でも、使えるAIは何度も入れ替わりました。実装の途中でClaudeのトークンが足りなくなり、ChatGPTの契約で動くCodexに任せる形に切り替えました。別の担当では、使っていたモデルの利用枠が尽きて、別のモデルで続けました。曲を作るモデルは、クラウドのサービスではなく手元のMacで動くものを選んだので、曲の指示も生成したデータも、Macの外には一度も出ていません。決まりも、その日のうちに変わりました。夕方に「音を出さない」と決めた決まりは、2時間後には「出してよい」に変わっています。

僕たちは小さな会社なので、使うAIを切り替えるのも、決まりを書き換えるのも、その場でできました。けれど大企業では、そうはいきません。使ってよいAIは会社ごとに違います。Claudeの会社もあれば、Copilotだけの会社も、Geminiだけの会社もあります。データをどこに保管してよいか、どの通信の方式を使ってよいか、外部とどうつなぐかの決まりも違います。そしてその決まりは、たいてい道具の進み方に追いついていません。道具は毎週変わるのに、社内の決まりは年に一度しか変わらないことも珍しくありません。

決まりが追いつくのを待っていれば、その間に1年が過ぎます。かといって決まりを無視すれば、安全も信頼も失います。だから、まず安全性を十分に確かめる。どのデータを外に出さないか、どこで処理するか、何を記録に残さないかを決める。そのうえで、本体の外に、その会社の決まりと同じ水準で守られた実行の場を組みます。データを手元から出さないモデルや、閉じた置き場所を使い、社内とはファイルを介して受け渡します。そこで得た結果と安全の根拠は、社内の決まりを書き換える材料として持ち帰ります。

決まりを破るのではなく、決まりが追いつくまでの間を、外で安全に埋める。これが8つ目です。この「外の場」については、最後にもう一度触れます。

9. 人が代わりに動く体制

外で越える仕組みを作っても、人の手でしか越えられない壁は残ります。今回も、新しい作業フォルダを信頼するかどうかの確認は、僕が押すしかありませんでした。既定の選択肢が「いいえ、終了」なので、自動で答えるとAIが終わってしまうからです。iPhone実機での確認には、ケーブルでのつなぎ込みが要りました。管理者パスワードの要るサーバーの点検は、2日以上、人の操作を待ち続けています。お金を払うことは、決まりでAIにさせていません。

どれも、AIの能力が足りないからではありません。本人の確認、物理的な操作、支払い、最後の承認は人に残すべきだと、僕たち自身が決めているからです。けれど、人に残した操作は、そのまま全体の詰まりになります。今回も、AIが10時間止まらずに進めた作業の後ろで、人の一押しを待つ項目が積み上がっていきました。

だから、人にしかできない操作を、待たせずに引き受ける人を置きます。AIの速さは、最後はこの人の手の速さで頭打ちになります。これが9つ目です。

10. 使う人の腕を上げるコーチング

この10時間の結果を左右したのは、僕が打ったわずかな言葉でした。方向を直した「spotifyをそのまま作るのが重要」と、決まりを書き換えた「音はいくら出しても構いません」です。こうした言葉がなければ、AIは間違った方向に10時間走り続けていたはずです。何を言うか、いつ言うか、何を言わないか。これは使う人の技術です。

同じAIを使っても、使う人の技術で結果は大きく変わります。そしてその技術は、専門知識ではなく、慣れと型で身につきます。社員一人ひとりがこの使い方をできるようになるまで、伴走して教える。これが10個目です。

11. 組織のルールづくり

今、僕のAIたちが守っているルールは、ほとんどが事故から生まれたものです。画面の切り替えは人だけがする。機密のデータは変更の記録に入れない。本番への反映と支払いには、人の言葉による許可が要る。別のAIからの連絡は、人の許可として扱わない。どれも、一度ひやりとしたあとに書き足したものです。

ルールは最初から完璧には作れない。事故のたびに書き足し、AIが読める場所で育てる

ルールは、最初から完璧には作れません。事故と気づきから、育てていくものです。そして、AIが読める場所に書かれていなければ、ルールとしては働きません。AIを前提にした組織のルールを作り、育て続ける。これが11個目です。

12. 導入の支援と選定

今回の開発は、選ぶことの連続でした。曲を作るモデルは、権利の条件を比べて3つの候補から選びました。実装を任せるAIは、トークンの残りを見てClaudeからCodexへ切り替えました。配信の置き場所は、無料枠の上限が1ファイル25MiB、1日10万リクエストであることを確かめてから決めました。道具の側も毎週変わります。僕たちは毎朝6時に、AIの道具の更新を調べる仕組みを動かしていますが、この日の朝も1つが新しい版に上がっていました。

何を選ぶかで、費用も、権利も、速さも変わります。そして正解は毎週変わります。組織に合うものを選び、入れて、更新し続ける。これが12個目です。

必要なのは、2層の環境

この開発で、僕はUXデザインの技術も、システム開発の技術も使っていません。モデルの賢さは、どの会社にとっても同じ条件です。差がつくのは、AIを動かす環境だけです。

差がつくのは、AIを動かす環境だけ。それは「ハーネス7つ」と「人と組織の備え5つ」の2層でできている

その環境は、2層でできています。1層目は、AIの周りに付けるハーネスです。組織のルールに沿わせる仕組み、道具、ガードレール、止まらない仕組み、安全な環境、検収、事故への備えの7つ。2層目は、人と組織の側の備えです。ルールの壁を外で安全に越える仕組み、人が代わりに動く体制、コーチング、組織のルールづくり、導入の支援と選定の5つ。

どれも、今回の10時間でも実際に現れた課題です。

ハーネス全体の構成図（将来の理想像）。中央にまとめ役AI・並列のワーカー・止まらない改善の輪・記憶（哲学のメモリー、会社の頭脳、多面的RAG）、左に人と組織の側の備え、右にMCPコネクター・毎朝の更新調査・費用の見張り、下に守りと運用

理念は、AIの中でもう一度動き出した

ここまでの出来事は、ShellBeeHakenで僕たちが目指してきたことと、ほとんど同じです。偶然ではありません。僕たちがハーネスに込めてきた考え方は、そもそもShellBeeHakenで培ったものだからです。

僕たちはチームに「待つ」ことを禁じました。今回のAIも、迷った項目を脇に置いて、ほかの作業を続けました。僕たちは、仕様から漏れていても、より良いと思う案があれば試してほしいと伝えてきました。今回のAIは、「店のBGM」から「Spotifyそのもの」へ、自分の判断で作り直しました。僕たちは、追加の見積もりなしでやり直せる単価を目指しました。今回、曲の生成が基準を外れた回数は28回ありました。それでも、作り直しを含むすべての生成にかかった電気代は、合わせて3〜5円でした。

そして、いちばん似ているのはここです。理念を掲げるだけなら、どの会社にもできます。同じように、「待つな」「自分ごととして考えろ」とAIの設定に書くだけなら、誰にでもできます。それらしく振る舞うハーネスは、すぐに作れてしまいます。けれど今回、AIを本当に動かしていたのは、書いた言葉ではありませんでした。止まるたびに組織の基準で判断を下す仕組みであり、「完成しました」を差し戻す検収であり、事故のたびにルールを書き足す運用でした。理念を掲げることと、それを本当に実行できる状態にすることはまったく別物だという、ShellBeeHakenで学んだことは、AIにもそのまま当てはまります。

違う点も1つあります。人は一度信じた理念を、自分の中に持ち続けます。AIは理念を信じませんし、会話が切れれば忘れます。だからAIには、同じことを毎回読ませ、毎回確かめる仕組みが要ります。

ShellBeeHakenで僕たちが磨いてきたのは、デザインや開発の技術そのものより、「理念を組織の中で本当に実行させる力」です。そして、その力こそが、AIのハーネスを作る力です。

作ることに、もう値段はつかない

今回、Spotifyの構成を持つアプリは10時間でできました。同じ日に並行して作らせたTikTokは、約14時間半で、本家の112の機能のうち103が動きました。作れなかった9つは、本当のお金のやり取りと、外部の身元確認が要る機能です。どちらも足りないのは技術ではなく、決済の契約と外部の審査です。

今、SpotifyやTikTokのシステムは、1日あればトレースできます。

開発の仕事は、長いあいだ「人が何か月働くか」で値段が決まってきました。作ることそのものが、高くて難しかったからです。その前提は、すでに崩れています。今回の1日は、それを改めて確かめただけです。作る主体がAIに移った以上、人の労働時間を値段の単位にする産業は、終わっていきます。

同じことを語る会社は、すでにいくつもあります。AIで速く安く作れる、と。けれど、その会社が約束するのが「作ること」までなら、もう意味がありません。作ることは、誰にでも1日でできるからです。

価値は、作った先にしか残らない

では、価値はどこに残るのか。

アプリを作れても、それだけでは事業になりません。Spotifyの強さはアプリではなく、1億曲を超える権利と、7億人を超える利用者と、その行動から育ったおすすめにあります。TikTokで作れなかった9つの機能も、足りないのは決済の基盤と外部の身元確認でした。

つまり、価値は作った先にあります。顧客、データ、販路、資本、ブランド。そうした大きな資産を持つ会社が、1日で作れる力を手にしたとき、初めて事業の形が大きく変わります。

僕たちの役割は、その接点に立つことです。大きな資産を持つ会社と組み、AIが止まらず、正しく、安全に働く環境を持ち込み、作ったものが事業として成功するところまで責任を持つ。作ることではなく、その先の成功にコミットする。それが、これからの僕たちの存在意義です。

対価は、変革の組織をつくる人件費だけになる

この変化は、お金の流れも変えていきます。

大きな会社が本気で変わろうとするとき、既存の組織の中では動けません。ルールも、承認も、予算の区切りも、AIの速さに合わないからです。だから変革を担う組織は、本体の外に「出島」として切り出されていきます。8つ目に書いた「外の場」は、まさにこの出島のことです。そして今回の10時間を支えたハーネスと、人と組織の側の備えは、その出島の中身そのものです。

そうなると、外部の会社に支払われるものも変わります。作業の対価は、もう払われません。作業はAIがするからです。残るのは、その出島を立ち上げ、動かし、育てる人の人件費だけです。そして、その先で生まれた成果の一部が、成功にコミットした者に分けられていきます。

開発会社がこれから受け取れるものは、出島をつくる人件費と、成功への分配だけになっていきます。

ShellBeeHakenを作ったとき、僕たちは「プロジェクトとしていくら売り上げたかではなく、いかに良いプロダクトを作るか」を掲げました。けれど、労働時間で値段が決まる仕組みの中では、その理念は最後まで稼ぎ方と噛み合いませんでした。作ることに値段がつかなくなった今、ようやく、良いものを作って成功させることと、報われることが、同じ線の上に並びます。

この流れが覆らないことは、僕たちがこの半年、現場で見続けてきたことであり、今回の1日でも改めて確かめられました。

ShellBeeHakenで信じてきたことを、AI時代の形で続けて、理念ややっていることの発信内容がおなじでも異なる結果をもたらせる人間でありたいです。

よくある質問

ハーネスエンジニアリングとは何ですか？

AIの周りに付ける仕組みを設計し、作り続ける仕事です。ハーネスはもともと馬具のことで、馬がどれだけ力強くても、手綱や引き具がなければ荷車は引けません。AIに渡す指示や文脈、使える道具、与える権限、止まっても続きから動かす仕組み、記録、出来を確かめる仕組みをまとめたものがハーネスで、モデルの力を仕事に変えます。

AIだけで、Spotifyのようなアプリは本当に作れますか？

発信元（ARCHECO）の記録では、一文の指示から約10時間で、ホーム・検索・ライブラリ・全画面のプレイヤーを持つスマホアプリができました。曲はAIが作った60曲、146分で、追加で払ったお金は0円です。一晩の8時間の連続再生では曲が205回切り替わり、止まった回数もエラーも0でした。人が打ったのは、方向を直す一言と「止めて」くらいです。

TikTokは、どこまで作れましたか？

約14時間半で、本家の公式ヘルプから拾った112の機能のうち103が、本家と同じ操作で動きました。ライブ配信も、ブラウザ同士をつなぐ形で数人まで動いています。作れなかった9つは、本当のお金のやり取りと外部の身元確認が要る機能で、足りないのは技術ではなく、決済の契約と外部の審査でした。

ハーネスには、どんな部品が要りますか？

記事では7つを挙げています。AIが組織のルールに沿って働く仕組み、AIに渡す道具、ガードレールの設計、止まらない仕組み、安全な環境、成果物を検収する仕組み、初期の事故に備える仕組みです。どれも、今回の10時間の中で実際に起きたつまずきと結び付けて書いています。

AIの周りの仕組みのほかに、人と組織の側では何が要りますか？

5つです。社内の決まりの壁を外で安全に越える仕組み、人にしかできない操作を待たせずに引き受ける体制、使う人の腕を上げるコーチング、AIを前提にした組織のルールづくり、導入の支援と選定です。AIの速さは、最後は人の一押しの速さで頭打ちになります。

UXデザイン会社や開発会社なら、AIを使いこなせるのではありませんか？

そうとは限りません。AIを使いこなす専門性と、AIでやりたいことの専門性は別物です。人の手順をそのままAIになぞらせると、いちばん大きな落とし穴にはまります。AIを使うのが上手い人は手順を自動化せず、AIが止まらず、組織の考え方に沿って判断し、自分で試して磨き続ける仕組みを作ってから、やりたいことを丸投げします。