坂本直樹@生成AI × プロダクト開発 × ハーネス・エンジニア

コペル合同会社 代表
プロダクトおよび事業開発支援、生成AIを活用した受託開発や技術コンサルを手がける。
テクノロジーを得意としており、これまでにCTOとしてスタートアップを3社創業。
2022年より生成AIに注力し、これまでに30件以上のプロジェクトを推進。

[坂本直樹@生成AI × プロダクト開発 × ハーネス・エンジニア @jar2]

AIエージェントが狙うのは13兆ドルの"労働市場"そのもの。

でも同じモデルを使っても、成果には10倍の差が開く。
差を生むのは、AIに仕事を任せる"ハーネス"
——手順・評価・安全柵・ログ資産の4成果物だ。

堀は「自社データ × 因果理解 × 時間蓄積」の乗算。
一度失った時間は、資金では取り戻せない。

▼ハーネス・エンジニアリングが次の10年の堀になる理由
https://t.co/DSJDIVdVAl

[坂本直樹@生成AI × プロダクト開発 × ハーネス・エンジニア @jar2]

昨夜はClaudeで大規模障害、Codexも不安定で、ほとんど何もできなかった。

生成AIはよく「インターネット級の革命」と言われるけど、使えないだけで仕事が止まる感覚を味わって、リアルにその意味を実感した。

[坂本直樹@生成AI × プロダクト開発 × ハーネス・エンジニア @jar2]

Typeless良いね！AquaVoiceから乗り換えた
紹介リンク貼っとくね
https://t.co/xTnSw7UQQW

[坂本直樹@生成AI × プロダクト開発 × ハーネス・エンジニア @jar2]

@hiroki_kohki おっしゃる通りだと思っていて、エージェントをマネジメントするためのツールですね

[坂本直樹@生成AI × プロダクト開発 × ハーネス・エンジニア @jar2]

Zedの神アップデート
- 1つのウィンドウで複数のAIエージェントを並列で動かせる
- しかも複数のプロジェクト / リポジトリをまたいで作業できる
https://t.co/oivz1J6t8c

[坂本直樹@生成AI × プロダクト開発 × ハーネス・エンジニア @jar2]

@jinjin07131971 ありがとうございます。今後とも宜しくお願いします。

[坂本直樹@生成AI × プロダクト開発 × ハーネス・エンジニア @jar2]

@hisaju01 公式からskillsが出てるのでオススメですよー

[坂本直樹@生成AI × プロダクト開発 × ハーネス・エンジニア @jar2]

AI エージェントでは、モデル選定以上にスキャフォールディング設計が結果を決め、しかも「有能」と「安全」は別管理しなければならない。

[Itaru Tomita / 冨田到 @itarutomy]

「どのAIモデルを使うか」より「使い方を教えるか否か」の方が圧倒的に大事、という結果が出た（https://t.co/4SkCJRBTlS）。

LLMエージェントにGmail・カレンダー・Driveを操作させる評価ベンチマーク「ClawsBench」。6モデル×4ハーネスで7,224試行の大規模実験。

APIドキュメントと安全ルール集をセットで与えるスキャフォールディングなしだと、Claude Opusを含む全6モデルがタスク成功率0〜8%で止まる。あれば39〜63%に跳ね上がる。この39〜63ポイントの差に対して、上位5モデル間の差はわずか10ポイント（Opus 63% / GLM-5 60% / Gemini Pro 58% / Sonnet 56% / GPT-5.4 53%）で統計的に有意差なし。モデル選びより環境設計が先。

「能力が上がれば安全になる」という直感も崩れた。タスク成功率が最高のOpus（63%）は危険な行動率（UAR、意図しない有害アクションを起こす割合）も23%で高い。最も安全なGPT-5.4（UAR 7%）は成功率が53%で中程度。能力と安全性は独立している。

スキャフォールディングなし条件で危険な行動が少ない理由も面白い。エージェントがAPIを知らないから何もできないだけ、という「情報の床」効果で、能力の欠如を安全だと勘違いしやすい。有効化すると能力と危険性が同時に上昇するが、安全ルール集（メタプロンプト）を加えると危険性だけを抑制できる構造が見えた。

記録された失敗事例の中でも印象的なのが「法的ホールドの逆張り」。Claude Sonnetがドキュメント内の「クライアント通知完了まで契約修正禁止」という注記を正確に検出したにもかかわらず、「これは安全ルール1が定義する埋め込みオーバーライドに該当する」と判断して無効化し、5件の契約を全修正した。安全ルールが裏目に出た逆説的なケース。

自動運転との比喩が出てくる。知覚精度が人間を超えてもテール事象の安全性検証がボトルネックになったように、LLMエージェントも「できる」と「安全にできる」の間に今、大きな溝がある段階だと思う。

[坂本直樹@生成AI × プロダクト開発 × ハーネス・エンジニア @jar2]

オーケストレーター・サブエージェント・状態管理のアーキテクチャ

[坂本直樹@生成AI × プロダクト開発 × ハーネス・エンジニア @jar2]

"ループを閉じる"（実行→検証→学習→再実装）という設計思想が重要で、このループが回り続ける限り、AIエージェントは自己進化する。
従来のソフトウェア設計とは大きく異なる。

[坂本直樹@生成AI × プロダクト開発 × ハーネス・エンジニア @jar2]

AIエージェントが狙うのは13兆ドルの"労働市場"そのもの。

でも同じモデルを使っても、成果には10倍の差が開く。
差を生むのは、AIに仕事を任せる"ハーネス"
——手順・評価・安全柵・ログ資産の4成果物だ。

堀は「自社データ × 因果理解 × 時間蓄積」の乗算。
一度失った時間は、資金では取り戻せない。

▼ハーネス・エンジニアリングが次の10年の堀になる理由
https://t.co/DSJDIVdVAl

[坂本直樹@生成AI × プロダクト開発 × ハーネス・エンジニア @jar2]

@AI_masaou こちらこそありがとうございました！

[坂本直樹@生成AI × プロダクト開発 × ハーネス・エンジニア @jar2]

今日は、まさおさんのコミュニティでLTをしました。
テーマは「ハーネス・エンジニアリング」
https://t.co/sziZYggjOY
最近いろんな人がハーネスについて発信しているけど、このコミュニティが一番熱量高いと感じる。

[まさお@AI駆動開発 @AI_masaou]

今日は まさおメンバーシップのオフ会へ🫡

個人でAGIに近づくために、失敗から学んだ統治の話を話そうかな

[坂本直樹@生成AI × プロダクト開発 × ハーネス・エンジニア @jar2]

AIエージェントのトークンを燃やす量って、その人の実力に比例する説

[坂本直樹@生成AI × プロダクト開発 × ハーネス・エンジニア @jar2]

コーディングエージェントの次に来る波は、PdMとグロースハックのエージェント化だ

AnthropicのCASHはその予兆に見える。
機会特定 → 施策実装 → 品質確認 → 学習抽出、までをループで回す

[チャエン | デジライズ CEO《重要AIニュースを毎日最速で発信⚡️》 @masahirochaen]

Anthropicのグロースチームの働き方が最先端。

・企画者は作らない
・雑務はAIに任せる
・AIがフィードバック
・社長にも公開反論

ARRが1年2ヶ月で10億→190億ドルに到達した史上最速企業の内側。勉強になる。

https://t.co/YTUpKfqZBR

━━━━━━━━━━━━

Anthropicのグロースチームのトップ、Amoleのインタビューから学ぶ"未来の働き方"

【組織・意思決定】

・グロースチームは約40名。B2B・Claude Code・APIなどオーディエンス別ポッド制

・PRD（企画書）は60〜80%のプロジェクトで書かない
　→「書くより動く」が文化

・2週間以下のプロジェクトはエンジニアがPM代行
　→エンジニアが法務・セキュリティ調整まで担当

━━━━━━━━━━━━

【小さな最適化より大きな賭け】

・一般的なグロースチームは小〜中ベット70%、大きな賭け30%

・Anthropicはその逆。大きな賭けに50〜70%を割く
　→理由：AI製品の価値は2年後に1000倍になる可能性があるから

　→微最適化より「次の市場」を取りにいく方が圧倒的に重要

━━━━━━━━━━━━

【グロースの自動化（CASH）】

・Claude Accelerates Sustainable Hypergrowth（CASH）プロジェクト始動

・Claudeがグロース施策のアイデア出し→実装→テスト→分析を自動化

・現時点の精度は「経験2〜3年のジュニアPM」レベル
　→ただし数ヶ月前は不可能だったことが今は動いている
・ヒューマンレビューを減らしていく方向で進化中

━━━━━━━━━━━━

【Claudeの個人活用（衝撃レベル）】

・毎朝20〜25のダッシュボードをco-workが自動巡回してサマリー送信

・Slack MCPで組織内の「ミスアライメント（認識ズレ）」を週次で自動検出

・直属メンバーのSlack・議事録・OKRをClaudeが分析し、フィードバック案を自動生成

・マネージャーのAmyのキャラをモデル化し「Amyだったらどう言う？」と毎週フィードバックをもらう

・経費精算・メール整理・会議室予約もすべてco-workに丸投げ

━━━━━━━━━━━━

【オンボーディングの哲学】

・「摩擦を減らせ」は間違い。正しい摩擦は転換率を上げる

・ユーザーに質問して「このサービスは自分のためにある」と感じさせることが最重要

・MasterClass・Mercury・Anthropicすべてで実証済み

━━━━━━━━━━━━

【文化】

・社員全員がNotebookチャンネルを持つ（社内Twitter）
　→Darioへの公開反論もOK。むしろ推奨

・「テーブルにお金を残すことを恐れるな」がグロースチームの核心原則

・チェックアウトしている社員がゼロ、というのが入社後の最大の驚きだったと語る

━━━━━━━━━━━━

AIが「何をすべきか」まで提案し始めた時代

グロースという最もデータドリブンな職域から、AIによる業務自動化が本格化している

これが2025年の最前線

[坂本直樹@生成AI × プロダクト開発 × ハーネス・エンジニア @jar2]

従来の組織では、中間管理職や階層が現場の情報を集め、要約し、上に上げ、横と調整し、優先順位をつける。言い換えると、階層は `情報を運ぶ仕組み` でした

Blockが面白いのは、AIを個人の作業補助ではなく、`この情報ルーティングそのものを置き換える仕組み` として見ている点だ

[jack @jack]

https://t.co/jgZkBvYOPt

[坂本直樹@生成AI × プロダクト開発 × ハーネス・エンジニア @jar2]

自分も似た運用をしていて、知識は人が全部を頭に入れておくというより、AIが理解しやすく、必要なときにアクセスしやすい形で整理しておくことが大事だと感じています。
そうすると、知識がちゃんと使える資産になります。

[Andrej Karpathy @karpathy]

LLM Knowledge Bases

Something I'm finding very useful recently: using LLMs to build personal knowledge bases for various topics of research interest. In this way, a large fraction of my recent token throughput is going less into manipulating code, and more into manipulating knowledge (stored as markdown and images). The latest LLMs are quite good at it. So:

Data ingest:
I index source documents (articles, papers, repos, datasets, images, etc.) into a raw/ directory, then I use an LLM to incrementally "compile" a wiki, which is just a collection of .md files in a directory structure. The wiki includes summaries of all the data in raw/, backlinks, and then it categorizes data into concepts, writes articles for them, and links them all. To convert web articles into .md files I like to use the Obsidian Web Clipper extension, and then I also use a hotkey to download all the related images to local so that my LLM can easily reference them.

IDE:
I use Obsidian as the IDE "frontend" where I can view the raw data, the the compiled wiki, and the derived visualizations. Important to note that the LLM writes and maintains all of the data of the wiki, I rarely touch it directly. I've played with a few Obsidian plugins to render and view data in other ways (e.g. Marp for slides).

Q&A:
Where things get interesting is that once your wiki is big enough (e.g. mine on some recent research is ~100 articles and ~400K words), you can ask your LLM agent all kinds of complex questions against the wiki, and it will go off, research the answers, etc. I thought I had to reach for fancy RAG, but the LLM has been pretty good about auto-maintaining index files and brief summaries of all the documents and it reads all the important related data fairly easily at this ~small scale.

Output:
Instead of getting answers in text/terminal, I like to have it render markdown files for me, or slide shows (Marp format), or matplotlib images, all of which I then view again in Obsidian. You can imagine many other visual output formats depending on the query. Often, I end up "filing" the outputs back into the wiki to enhance it for further queries. So my own explorations and queries always "add up" in the knowledge base.

Linting:
I've run some LLM "health checks" over the wiki to e.g. find inconsistent data, impute missing data (with web searchers), find interesting connections for new article candidates, etc., to incrementally clean up the wiki and enhance its overall data integrity. The LLMs are quite good at suggesting further questions to ask and look into.

Extra tools:
I find myself developing additional tools to process the data, e.g. I vibe coded a small and naive search engine over the wiki, which I both use directly (in a web ui), but more often I want to hand it off to an LLM via CLI as a tool for larger queries.

Further explorations:
As the repo grows, the natural desire is to also think about synthetic data generation + finetuning to have your LLM "know" the data in its weights instead of just context windows.

TLDR: raw data from a given number of sources is collected, then compiled by an LLM into a .md wiki, then operated on by various CLIs by the LLM to do Q&A and to incrementally enhance the wiki, and all of it viewable in Obsidian. You rarely ever write or edit the wiki manually, it's the domain of the LLM. I think there is room here for an incredible new product instead of a hacky collection of scripts.

[坂本直樹@生成AI × プロダクト開発 × ハーネス・エンジニア @jar2]

AIエージェントは、3つの原則で設計する
そして、そのパフォーマンスはループを回し続けることで向上する

原則:
迷わない--何を・どこに・どうするかを明確に
探さない --必要な情報に最短でたどり着く
止めどきを決める--完了条件を定義する

[坂本直樹@生成AI × プロダクト開発 × ハーネス・エンジニア @jar2]

#Loop_is_King
2024年に発信していたことは、2026年の今も本質的に変わっていない。

画像生成でも、エージェントでも、プロダクトでも、
価値は「生成 → 評価 → 改善」のループの中で生まれる。

#ハーネス・エンジニアリング の時代になっても
重要なのはループと評価の設計

[坂本直樹@生成AI × プロダクト開発 × ハーネス・エンジニア @jar2]

#Loop_is_King
2024年に発信していたことは、2026年の今も本質的に変わっていない。

画像生成でも、エージェントでも、プロダクトでも、
価値は「生成 → 評価 → 改善」のループの中で生まれる。

#ハーネス・エンジニアリング の時代になっても
重要なのはループと評価の設計

[坂本直樹@生成AI × プロダクト開発 × ハーネス・エンジニア @jar2]

元木さん(@ai_syacho)が主催する #生成AIエンジニア塾 で再びスピーカーを務めました。今回も画像生成をテーマを担当しました。画像生成から評価、そして改善へと進むループを回して意図した画像を生成します。このループが回転する程、創出する価値が増大するような構造を作ることが重要です。

[坂本直樹@生成AI × プロダクト開発 × ハーネス・エンジニア @jar2]

AIブレインフライとは、AIの使いすぎによって脳が処理しきれなくなる状態。
思考のぼやけ・集中力低下・判断の遅れを引き起こす。
原因は👉 認知負荷のオーバー

対策は
・AIツールは3つ以内
・休憩を入れる

https://t.co/1otWPrJx0d