情報収集のために日々 X のタイムラインを開いているが、正直もう食傷気味だ。
「ハーネスエンジニアリングの最先端が凄い」
「RAG 不要論」
「PdM を廃止して FDE へ」
「時代は .md ではなく .html だ」
挙げればキリがない。AI をどう使えばパフォーマンスが上がるのか、AI のアーリーアダプターが鳴り物入りで発信し、それを見たアーリーマジョリティが熱狂している。
けれど、今自分が向き合っているのは、もっと面白く、難しい問いだ。エンジニアのみならず、ナレッジワーカーも擁する組織にAIをいかに張り巡らせて事業をスケールさせるか。自分はそんな議論が出来る人を求めている。
StoreHero とその AI 戦略
StoreHero は Shopify に特化し、独自のグロースプラットフォームと専門コンサルティングを組み合わせて EC サイトの売上拡大を支援する「グロース支援サービス」だ。社内の代表的なセクションとして、Shopify マーチャントのカウンターパートとしてコンサルティングを行うグロースパートナー（以下「GP」）チーム、施策を実装する GOps チームがあり、また、グロースプラットフォームと呼ばれるデータの可視化や自動化・効率化を行う基盤アプリケーションを開発する Dev チームが存在する。
2026 年 1 月、世間的に AI がエンジニア向け以外にも有用であることがわずかに認知され始めた、ちょうど Cowork がリリースされる少し前だったか。開発チームのリソースをグロースプラットフォーム x AI 強化に向けるのではなく、GP の能力をエンパワーするために振り切る意思決定をした。理由は大きく2つある。1つ目は、StoreHero の価値の源泉がShopify x グロースの圧倒的な経験値であり、価値を体現するのは人間だからだ。2つ目は、AI の進化によってプロダクトのコモディティ化は今後加速していくし、Anthropic などメジャーな AI プロバイダーの驚異的なリリース速度で、組み込んだ技術がまたたく間に古びて負債になりうる。総合的にみて、エンドユーザー向けのAIプロダクト開発を頑張るより、社内向けに AI を活用していく方が機動力高くスケールを目指せると判断した。
この記事を書いているのが5月11日なので、ちょうどそんな意思決定をしてから約 4 ヶ月、これまでやってきた泥臭い活動とそこから得られた知見を共有したい。
1. ナレッジワーカーへの Cowork 導入
Dev チームには前年より全メンバーに Claude Code Max プランが支給されていたが、2026 年 1 月からナレッジワーカー向けに Cowork を Team プランで招待し、3月までには全社員に導入が完了した。もちろん Claude Code の導入も検討した。後述するハーネスを実装する際に Claude Code と Cowork を両方サポートした実装というのは骨が折れるし、Claude Code では簡単に出来るのに Cowork では一工夫しなければいけないことも結構あるので、Claude Code に絞った方が楽ではある。しかし、その不便さのトレードオフで Cowork の方が安全性は高い。実際にナレッジワーカーの Claude との会話履歴を観察していると、実に盲目的にコマンド実行を承認することに驚いた。そうしたことから、安全側に倒したこの判断は妥当だと考えている。
2. StoreHero 流のハーネスエンジニアリング
ハーネスエンジニアリングの定義は様々だが、私は非常にシンプルに「エージェントを、意図したとおりに働くように仕向けること」だと捉えている。StoreHero の場合、ナレッジワーカーの各端末に存在する Claude が、ユーザーの技量の多寡に拘らず、こちらの設計意図から逸脱せずに仕事をすることである。
ナレッジベースリポジトリの整備
先ほど圧倒的な経験値こそが StoreHero の価値の源泉だと述べたとおり、その経験値を言語化し、エージェントが活用できるようにすることこそ初手だと考えた。そこで、組織のナレッジを集約する Github リポジトリを作成し、そこにあらゆるナレッジを管理することとした。しかし、言うは易く行うは難し、社内の資料をかき集めたところで組織のナレッジと呼ぶには到底及ばない。そこでどうしたかというと、社長の黒瀬を「ここだけは人間が泥臭くやらないとダメなんです」と説得して、まずは断片的な言葉に変えてもらい、その間にある隠れた文脈をエージェントに拡張させ、さらに黒瀬がその内容をレビューして納得できる状態に仕上げる、というプロセスを一つ一つ繰り返した。一つのナレッジにつき多いもので 4,000 行に及ぶものもあるが、こうしたことを現在進行系で泥臭く続け、今ではナレッジベースに 70 種近いナレッジ（Agent Skills）が溜まっている。
Agent skills & MCP
先述したナレッジベースリポジトリを Marketplace 化し、蓄積したナレッジをもとに 70 種近い Agent skills を適切な粒度の Plugins として社内メンバーに配布している。また、skill 内で利用する外部データなどのうち、公式のコネクタで賄いきれない部分は独自に Remote MCP Server を立てて tools を提供している。
Storage: Google Drive for Desktop
StoreHero では組織のナレッジとは別軸で、もうひとつ重要なコンテキストがある。支援先マーチャントと伴奏してきたあらゆる歴史である。組織のナレッジを太い幹にして、それにマーチャントごとの歴史を掛け合わせることでよりパーソナライズされたきめ細かい支援が可能になる。
こうした情報を活用するには広義の RAG が必要であり、様々な検討をした結果ファイルシステムベースの Agentic RAG を、Google Drive for Desktop + Cowork で実現するのが最適だと結論付けた。
実は、この記事を書いている今日現在では共有ドライブの仮想フォルダを Cowork の作業フォルダに指定することが出来るのだ。この方法であれば、ナレッジワーカーはそれぞれの端末で今までどおり作業する体験を全く変えることなく、また、開発コストをほぼ費やすことなく、マーチャントごとのコンテキストを各エージェントに届けることが出来るようになる。
Waggle: Agent 同士のタスクハンドオフ
エージェントをはいと渡して、ナレッジワーカーは突然業務効率を何倍にも上げることはできるだろうか？いや、ならない。アンケートを取れば多くは上がったと答えるであろうが、そのほとんどは幻想だろう。エージェントを使いこなせる人とそうでない人の考察は世の中に数多くあるが、私が思うエージェントをうまく使いこなすポイントは2点だ。
1つ目は、エージェントを並列作業させられるか。エージェントを使い始めた人は、ほぼ全員が、1セッション1タスクを直列で一つずつ完了させていく。それでも人間がやるとかなり時間がかかる作業を短時間で終わらせてくれるので「凄い効率化だ」と感じる人は多いはずだ。しかし、一歩引いてみると、エージェントの作業過程をじっと見守っている時間が非常に長いことに気づく。
エージェントの使い方が上手い人は、いくつものセッションを並列で走らせてマルチタスクを消化する。そして同時に、次の2つ目のポイントを大事にしている。
調査と計画に多くの時間を使うこと。並列作業を上手く行うためには、各エージェントの途中経過を気にすることなくお任せできる状態にしなくてはいけない。そのために重要なことは、事前の調査・計画を入念に行うことだ。計画には実行手順とともに Acceptance Criteria を含め、エージェント自身が成果を検証できるようにしておくことが望ましい。
この2つのポイントを実践するにはコツというか慣れがいる。そしてそれを一人一人ナレッジワーカーに教え込んでいてはスケールしない。そこで Waggle という OSS を作った。
Waggle は Claude 向けの Plugin で、私の Claude とあなたの Claude がタスクをハンドオフするためのプロトコルを定義する。さらに、準備ができたタスクを Scheduled Tasks で並列実行する仕組みも提供する。これを全社的に導入して、エージェントの能力を人間がボトルネックになることなく最大限活かせる状態を目指した。
OpenTelemetry ログ分析と自己改善
ハーネスに異常や改善点がないかをモニタリングするため、OpenTelemetry のデータを Grafana Cloud に連携している。
基本的な利用状況はダッシュボードで確認出来るようになったが、それを眺めているだけではなかなか生きたインサイトを導出できない。そこで、提供した Agent skills や MCP が正しいタイミングで利用されているか（または使うべきタイミングで漏れていないか）をエージェントが生ログから分析する /harness-analyzer スキルを作成して定期的に実行し、問題が見つかった場合には PR を作成するサイクルを設けている。
語られる馬具、語られない乗り手
以上が StoreHero が取り組んでいるハーネスエンジニアリングの概要だ。話は冒頭に戻る。世の中こんな話ばかりでつまらない。
みんな俺の馬具（ハーネス）凄いだろと喧伝するが、馬（エージェント）に乗る人間や組織について誰も多くは語らない。馬具はあくまで道具である。どんなに優れた馬具を馬に装着してみたところで、馬はひとりでには走り出さない。馬を動かすのは人間だ。そして、その人間の行動をハーネスでコントロールすることは出来ない。エージェントを組織に張り巡らすための一番の壁はここにある。
GP チームの実態調査
私たちは、GP がエージェントをフル活用している状態を目指している。そのためには、まず GP が
- 現状どういうタスクをどういう意図で、どのようにエージェントに委譲しているか
- どういうタスクを人間の手で行っているのか
を知る必要があった。しかし、社内の共有された資料だけでは全くと言っていいほど読み取れなかった。
唯一の手がかりであった週次計画シートというスプレッドシートも、とても理解を助けるレベルではなかった。解像度の高い情報は担当者の頭の中だけにあり、GP リーダーもそのことを課題に感じていた。
そこで次に、Dev チーム主導で GP メンバーを集めて2度のワークショップを開催した。目的は、GP が組織として成熟しておらず個人の集合体であるという仮説のもと、成熟することを妨げる問題を探ることであった。仮に個人の集合体の状態だとすると、チームメンバー間の情報交換や連携が生まれず、エージェントの正しい利用に向けた取り組みがスケールしないので、これは大きな問題であった。
ワークショップの結果見えた中心的な課題は、GP 担当者が各マーチャントについて抱えている暗黙知が膨大だということであった。その結果、
- コンテキストを伝えるのが大変なため、タスクを誰かに委譲するよりも自分でやってしまった方が早い
- チーム内のミーティングも、コンテキストが見えないから伝わらない意味のない時間が多い
という思考に陥ってしまい、ますます個人に閉じる悪循環が発生していた。
タスクを誰かに委譲しにくいということは、エージェントにも委譲しにくい状態になっていることが予想される。GP にエージェントをフル活用してもらいたい Dev チームにとっても大きな問題である。Dev チームが次にやらなければいけないのは、GP チームに潜む暗黙知を徹底的に形式知に変えることだと分かった。
GP チームと Dev チームの統合
難しい問題を解決するには、よりシンプルなアプローチを私は好む。GP チームと Dev チームを「チームやまびこ」という一つのチームに統合した。
チームで最初にやったことは、チームのリズムを作ることだった。Dev チームではもともとスクラムを取り入れており、3本柱である透明性、検査、適用が今の GP チームにも必要だと感じたことから、スクラムをナレッジワーカー向けにカスタマイズして、1. 週はじめ会（スプリントプランニング）、2. 朝会（デイリースクラム）、3. 振り返り会（レトロスペクティブ）※実施準備中、の3つのセレモニーだけを行うことにした。
その次にやったのは、チームのリズムにエージェントを組み込むことであった。ここで、先述したナレッジベースや Google Drive にドキュメント化されたマーチャント支援履歴といったエージェントハーネスを活かすことができる。
具体的には、yamabiko という Claude Plugin を作り、/drafting-weekly-plan、/running-daily-checkin、/running-weekly-retro という3つのコアスキル、そして状態を Live artifact で人間向けに可視化する /visualizing-gp-dashboard というスキルを開発した。
drafting-weekly-plan スキル
週はじめ会向けのスキル。マーチャントの中長期的な目標や取り組み中の施策状況、最近のトピックなどをエージェントが Google Drive の state ファイルから読み取り、スプリント週のプランを構築して人間が承認する。プランは、Waggle と連携して Exection Plan, Acceptance Criteria まで具体化し、他チームメンバーやエージェントにハンドオフしやすい状態にしておく。
running-daily-checkin スキル
朝会用のスキル。スプリントアイテムのステータス更新と、障害があった場合にはその内容を Google Drive の state ファイルに追記する。
running-weekly-retro スキル
スプリント期間に Google Drive 内で作成/更新された物理ファイルやマーチャントとのやり取りの情報をエージェントが読み取ったうえで担当者と振り返りを行い、Google Drive の state ファイルをメンテナンスする。
visualizing-gp-dashboard スキル
state ファイルはエージェントが読み書きしやすいデータ構造に設計しており、人間が読むためのものではない。state の内容、スプリントアイテムや Waggle タスクの内容を集約し、人間がチームメンバーの状況を理解しやすい UI を提供する可視化スキルを作った。UI は Cowork の Live artifacts を利用して各担当者の端末に永続化される。共有しやすいようにダッシュボードアプリを作ればいいじゃないか、という声もありそうだが、極限まで作らない、特に UI に関しては最早エージェントを使えばナレッジワーカーでもすぐに作れてしまうので、Dev チームがユーザー全員にフィットした UI を開発するよりも、エンドユーザーが自分に合うものを自分で作ればいい、という哲学が影響している。
StoreHero の現在地
今週まさに、これらのスキルをチームやまびこに展開して人間のルーティンの中にエージェントを組み込み始めるところだ。
次にやることは、Dev チームが GP のタスクを剥がして、代わりにエージェントにタスクを実行させることである。チームやまびこ内の透明化が進み、タスクの実行計画が具体的で洗練されたものになればこれが可能になると思っている。逆にうまくタスクを剥がせないということであれば、透明性、タスク作成の精度に課題が残っていると判断して、Dev チーム自身で改善を行っていく。
Dev チームが GP のタスクを上手に剥がせるようになった時には、GP が自分のエージェントに対してももっと上手にタスクを渡せるようにはずだ。その時が、チームとしてスケールする瞬間だと思っている。
まだ動き出したばかりなので今日はここまでだが、今後チームやまびこがどうなったか、続報の記事を書ければと思っている。
最後に
この Dev チームの動きは FDE なのか？そんな議論には微塵も興味がない。解決したい課題とAIエージェントの日々更新される能力に愚直に向き合い、その時に最適と思われる方法を選んで問題解決に臨んでいるだけだ。エージェントの急速な進化はまだまだ続くだろう。カオスな状況の中で、新しい型やラベルを定義して安心したい気持ちも分かるがそんなものまたすぐ古くなる。もっとカオスのまま楽しもう。
もう一つ、AIエンジニアは技術ばかりを追わず、もっと人間の営みと向き合おう。ハーネスエンジニアリングなどエージェントのコントロール手法を磨いたところで、その外側にボトルネックが待っている。組織のメンバーをどうやって馬に乗らせるか。そのためには今の組織をダイナミックにデザインし直さなきゃいけないかもしれない。今私が最もチャレンジングで、最も面白いと思うのはこの領域だ。
Discussion