AIに仕事を任せる会社が増えました。そこで次に問題になるのは「出力の品質が安定しない」ということです。
巷で騒がれていた「ハーネス」というものです。この記事は、2026年7月末時点でKOIYALがどのようにハーネスを構築してAIネイティブな会社として運営しているかについてです。
ハーネスとは何か
ハーネスはもともと馬具や安全帯を指す言葉で、AIの文脈では「モデルを制御して安全に働かせるための周辺装置」を意味します。
前提にしている考え方はシンプルです。AIモデルは数か月ごとに新しくなりますが、モデルを乗り換えるたびに仕事の質が変わるようでは業務に使えません。だから品質はモデルに頼らず、手順書、評価の仕組み、権限の設計といった周辺に持たせます。モデルが替わっても、ハーネスは会社の資産として残ります。
KOIYALのハーネスの実体は、1つのgitリポジトリです。会社の運用ルール、手順書、評価基準、禁止事項がすべてテキストファイルとして入っていて、AIエージェントは毎回ここを読んでから仕事を始めます。
構成要素
1. 指示書
リポジトリの入口に、作業開始時に必ず読むファイルを置いています。事業の全体像、やってはいけないこと、どの作業でどの手順書を参照するか。人間の新入社員に渡すオンボーディング資料と同じ位置づけです。
やってはいけないことは、心構えではなく操作名で列挙しています。実物から抜き出すと、APIキーや秘密鍵の表示・本番デプロイ・DB削除・DNS変更・課金設定の変更・メール送信・SNS投稿・顧客データの外部送信。いずれも「必ず人間の承認が必要」と明記してあり、AIはこのリストを読んでから作業に入ります。
指示書で大事なのは、内容の出来より「必ず読まれる場所に置く」ことだと考えています。守らせたいルールが人の記憶やチャットの過去ログにしかない状態では、AIは守りようがありません。
2. skill: 繰り返す手順の台本（18本）
記事作成、スライド生成、SNS分析、週次の締め処理など、繰り返し発生する仕事は手順書（skill）にしています。2026年7月末時点で18本あります。
ポイントは、賢いモデルでなくても実行できる粒度で書くことです。たとえばコンテンツ制作のskillには、企画を読者セグメントと認識段階から決める順番、引用してよい実績の範囲、媒体ごとのサムネイルサイズ、公開前チェックの項目までが台本として書いてあります。「いい感じにやって」を残すと、モデルの調子と運で品質が揺れます。判断基準を文章に落とし切る作業がskill化です。
自作だけではなく、外部の良い手法も取り込みます。ただしツールを本体ごと導入するのではなく、考え方だけを自社の規約に合わせて書き直してから入れる方式です。外部の手順書には自社の禁止事項が入っていないためです。
3. SOP: 定型業務の実行台本（8本）
skillより硬い、順番どおりに実行する定型手順はSOP（標準作業手順書）として分けています。現在8本で、それぞれコマンド1つで呼び出せます。
実際にあるのは、ブログ記事の追加から表示検査、予約公開までを通しで行うもの。1本の記事をX・Instagram・Threads・Facebook・noteへ展開し、途中に承認を3回挟んで投稿と記録まで行うもの。新しい事業を始めるときに必要なファイル一式を規約どおりに揃えるもの、などです。
skillと分けている理由は自由度の違いです。skillは判断の余地を残した台本、SOPは寄り道を許さないチェックリストつきの実行手順で、決まり切った作業ほどSOP側へ寄せます。
4. evaluator: 出力を審査する評価器（9本）
文章・デザイン・コード・セキュリティ・SEOなど、領域ごとに評価器を9本用意しています。中身は「何を確認し、何が出たら差し戻すか」を書いたチェックリストです。
たとえばセキュリティの評価器は、認証、権限、Webhook、外部への送信を伴うコード変更で必ず通します。デザインの評価器は、ブランド規約からの逸脱、煽りすぎの見た目、素材の使い回し感を差し戻します。
作る側と審査する側の基準を分けて文書化しておくと、生成したAI自身に別の視点で検査させられます。同じAIでも、作っているときの文脈と、審査のチェックリストを持たされたときでは見えるものが違います。
5. 機械検査: ルールは文書とスクリプトの二重持ち
表記ルールは文書で持つだけでなく、検査スクリプトにもしています。検出するのは、同じ語尾が3文以上続く、一文が長すぎる、使わないと決めた言い回しがある、といった項目です。デザインにも同様の検査があり、文字のはみ出しやコントラスト不足は目視の前に機械で拾います。SNS投稿のスクリプトには、本文に外部URLが混ざっていたら投稿自体を止める逆方向のチェックも入れてあります。
実はこの記事の下書きも、検査に5か所引っかかって直しています。ルールを増やすたびに検査もコードにする。これを続けると、品質チェックの大部分が人の集中力に依存しなくなります。
6. 権限設計: 不可逆な操作は機械的に止める
AIエージェントには広い権限を与えつつ、後戻りできない操作だけは設定ファイルで機械的にゲートしています。デプロイ・公開・送信・削除・課金に類する操作は、実行前に必ず人間の承認が挟まります。
さじ加減として大事にしているのは「普段は止めない」ことです。読み取りや下書きの生成まで毎回許可を求める設定にすると、確認疲れで人間が何でもOKを押すようになり、かえって危険になります。日常の作業は自動で通し、取り返しのつかない操作だけを確実に止める。確認の回数を絞るほど、1回の確認の質が上がります。
「AIを信頼するかどうか」を毎回悩むのではなく、信頼しなくても事故が起きない構造を先に作る、という発想です。
7. セッション運用: 作業状態の可視化と引き継ぎ
長い作業ではAIの作業記憶（コンテキスト）が限界を迎えます。KOIYALでは使用率と残量を常時1行で表示する仕組みを自作し、閾値を2段に分けた運用です。使用率50%で「ここから大きい作業に入ってよいか」を予告し、60%で作業の区切りに状態をファイルへ保存してから記憶をリフレッシュします。そのため、次に行うタスクがセッション中のコンテキスト量を超えてしまいそうでも、事前にそれを防ぐ仕組みとなっています。
保存するのは作業ログではなく、採用した案、却下した案、却下した理由のセットです。結論だけ残しても、判断の理由が消えると次のセッションで同じ検討を繰り返すからです。保存ファイルの見出しには、セッション中に決めたこと、確立した制約と未検証の事項、復帰後の最初の一手までを必須項目として定めています。
8. 秘密情報: 値をAIに見せない
APIキーやトークンの値は、AIとの会話にもファイルにも出しません。1Passwordの秘密参照を使い、AIはどこにあるかだけを扱い、値は実行時にプログラムへ直接渡ります。
夜間の定時実行のような人が立ち会わない処理は、権限を絞ったサービスアカウントに移してあります。引き継ぎ用の保存ファイルにも値は書かず、どの保管庫のどの項目かという参照名だけを書く決まりです。万一ファイルが外に出ても、漏れるのは場所の名前だけで済みます。
具体例: 1本のブログ記事が公開されるまで
この仕組みが実際にどう動くか、記事公開の流れで見てみます。
- AIが記事ルールと表記規範を読み、下書きを書く
- 表記の検査スクリプトを実行し、引っかかった箇所を直す
- 人間が全文を確認して、内容の裁定をする
- 承認後、公開用SOPに沿ってサイトへ実装し、表示崩れを検査する
- 公開操作の直前で承認が挟まり、人間がOKを出して公開される
AIが担当するのは執筆と検査と実装で、人間が担当するのは裁定と承認だけです。この分担が崩れないことを、手順書と権限設計の両方が保証しています。
ちなみにこの記事自体も、この流れをそのまま通って公開されています。
もう1つの具体例: 1本のSNS投稿が世に出るまで
ブログより頻度が高いSNS投稿は、事故の機会も多いぶんゲートを厚くしています。
- AIがSNS規範（媒体別の口調・構成・禁止事項）を読み、数日分の投稿文をまとめて下書きする
- 人間が全文を確認し、直すところは直して裁定する
- 承認された本文だけがテキストファイルとして所定の場所に置かれ、投稿スケジュールに登録される
- 投稿時刻になると自動実行される。ただし投稿スクリプト自身が最後の検査をする。本文に外部URLが混ざっていたら、その投稿は実行されずエラーで止まる
- 結果はログに残り、翌朝に発火を確認する
ポイントは4番です。承認済みの文面でも、機械はもう一度疑う。人間の見落としと、承認後のファイル差し替えミスの両方をここで拾えます。逆にFacebookページだけはURL必須の運用なので、URLが無いと止まる逆向きの検査が入っています。ルールが媒体ごとに違うなら、検査も媒体ごとに分けるということです。
ハーネスはどう育つのか
作って終わりではなく、日々の差し戻しから育てています。育て方はシンプルで、人間が直した差分を、次のルールにするの繰り返しです。
たとえば最近の実例です。AIが書いたSNS投稿の下書きを代表が直接編集したので、その差分を読み比べたところ、直し方に明確なパターンがありました。断定で締めた文が疑問形に緩められている。抽象的な表現に具体例が1つ足されている。日付のない予告が削られている。この3つをその場で表記規範に追記し、以後の下書きは最初からそのルールで書かれるようになりました。
合格した文章より、直された差分のほうが資産になります。合格文には「なぜ良いか」が書かれていませんが、差分には「何が違うか」がそのまま写っているからです。ハーネスの成長速度は、この差分をどれだけ拾えるかで決まると考えています。
よくある誤解
導入の相談でよく出る誤解を3つ挙げておきます。
「ルールを文書化すれば守られる」。守られません。守られるのは、作業の入口で必ず読まれる場所に置かれたルールと、機械検査になったルールだけです。共有フォルダの奥のガイドラインは、人にもAIにも読まれません。
「ハーネス=禁止事項のリスト」。禁止リストは一部にすぎません。分量として多いのは、むしろ生産のための台本です。どう書くか、どう作るか、何をもって合格とするか。守りだけのハーネスは仕事を遅くしますが、生産の台本を含むハーネスは仕事を速くします。
「大きな会社が体制を組んでやるもの」。KOIYALは少人数の会社で、ここで紹介した仕組みは1人と数体のAIエージェントで回っています。むしろ人手が少ないほど、判断基準を人の頭の外に出す効果は大きくなります。
作り方の原則
KOIYALがハーネスを作るときの原則は3つです。
- 決定論的に処理できるルーチンはスクリプトにする。AIを呼ぶのは判断、生成、言語化が必要な部分だけ
- 手順書は、性能が一段低いモデルでも実行できる粒度で書く。モデルの賢さに寄りかかった手順書は、モデル更新のたびに壊れる
- 同じ手順を2回書いたら手順書化を検討する
正直な注意点
うまくいっている話だけでは実態が伝わらないので、コストも書いておきます。
まず、ハーネスは一度には作れません。たとえばコンテンツ制作の手順書は、人間とAIで39回のすり合わせを重ねてようやく85点です。
85点というのは正直なところ今の自分に出せるであろう100点を85点としています。つまり最終的には人間側のスキルがないと100点の創作物を作ることはAIと一緒に作ると言っても無理だと言うことです。
これはなにもライターとして何年も活動していないから、デザイナーとして何年も活動していないからというだけでなく、そもそもスキルが100点で留まることなんてないのだから成長のポテンシャルを加味してもあと15点は絶対に上げられる、もっと詰められるということです。
次に、ハーネスがあってもAIは間違えます。いくら現時点の最大値を決めたとしても減るのは間違いの数と、間違いが事故になる確率です。80~85点（スキルレベルで90~100点）が常に出せる状況にはなったと思うのが良いと思います。
基準の言語化には時間がかかりますし、見落としもあります。だからこそ不可逆な操作の人間承認は最後まで残しています。
最後に、手順書は現実とずれていきます。運用しながら「手順書と現実がずれたら手順書を直す」を回し続ける前提が要ります。
KOIYALの見解
AI活用の成否を分けるのは、どのモデルを使うかよりも、モデルの周りに何を組むかだと考えています。
モデルは全社共通の道具ですが、ハーネスには自社の判断基準、自社の表記、自社の禁止事項が入ります。つまりハーネスは他社と差がつく部分であり、蓄積すればするほど、新しいモデルが出た瞬間にその性能を安全に取り込める体質になります。
この仕組みづくりを支援しています
この記事で紹介した仕組みを各社の業務に合わせて一緒に作成することも可能です。手順書の書き方、評価基準の言語化、権限設計まで、実際に運用しているものをベースにお手伝いします。
ハーネスの整備をいきなり全社で行うのは難しいと思うので、まずは経営者1人に対してマンツーマンで伴走支援することをおすすめしております。
ご相談は無料です。お問い合わせフォームからご連絡ください。