同じ注意を、何度AIに打ち込んでいるか

AIに仕事を頼むたびに、同じ注意書きを打ち込んでいる人は多いはずです。日付は西暦で統一してください。請求書の宛名には御中を付けてください。レポートの数字には必ず前月比を添えてください。1回あたりの手間は数十秒でも、毎日続けば無視できない時間になりますし、打ち忘れた日の成果物はルールから外れたまま出ていきます。

チームで使う場合はもっと深刻です。10人が同じAIツールを使っていても、指示の出し方が10通りあれば、出てくる成果物も10通りにばらつきます。ベテランの経理担当が細かい条件まで指定して高品質な仕分け結果を得ている隣で、入社2年目の担当者は前提を伝えきれず、毎回手直しに時間を取られている。こうした光景は、AIを導入した中小企業のほとんどで起きています。

つまり問題はAIの性能ではありません。会社のルールが、人の頭の中にしかないことが問題です。ルールが明文化されておらず、明文化されていてもAIに渡す仕組みがない。だから毎回、個人が思い出しながら打ち込むしかない。この構造を変える動きが、2026年に入って形になってきました。今回はその象徴となる公開事例を起点に、非エンジニアの仕事にどう効くのかを考えます。

何が公開されたのか

イスラエルの技術コンサルティング会社Tikalが、adlc-team-skillsというリポジトリをGitHub上で公開しました。リポジトリとは、ファイル一式をインターネット上で共有・管理する置き場のことです。ADLCはAI Development Life Cycleの略で、AIを前提にした仕事の進め方の全体像を指します。

このリポジトリの中身は、チームのコーディング標準です。コーディング標準とは、プログラムを書くときの命名の付け方やチェックの観点など、チームで揃えるべき作業ルールを指します。それをスキルという形式のファイル群にまとめ、AnthropicのClaude CodeとOpenAIのCodexという2つのAI作業ツールの両方で読み込めるようにしてあります。Claude Codeは指示を出すと自分でファイルを開き、調べ、成果物を作ってくれるAIエージェント（人の代わりに一連の作業を進めるAI）で、CodexはOpenAI社が提供する同種のツールです。

中身がプログラミングの話なので、自分には関係ないと感じたかもしれません。私はそう思いません。注目すべきは規約の中身ではなく、チームのルールを配れる形式にしたという事実のほうです。コーディング標準は、あくまで題材のひとつにすぎません。同じ形式で、経理のルールも、契約書チェックの観点も、レポートの書き方も配れます。この記事で掘り下げたいのはそこです。

スキルとは何か: AIが自分で開くマニュアル

スキルとは、手順やルール、判断基準を書いたテキストファイルのことです。実体はMarkdown（見出しや箇条書きを記号で表す、メモ帳でも書ける単純なテキスト形式）で、AIは仕事の種類を認識すると、該当するスキルを自分で開いて読み、その内容に従って作業します。

人間の新人にマニュアルを渡す場面を思い浮かべてください。口頭で毎回教えるのではなく、文書を渡しておけば、新人は必要なときに自分で読み返します。スキルはそのAI版です。たとえば請求書まわりのルールなら、こんな数行のファイルで成立します。

---
name: invoice-rules
description: 請求書を作成・確認するときに必ず読むルール
---
- 宛名には必ず御中を付ける
- 振込期限は発行日の翌月末とする
- 金額は3桁区切りのカンマを入れる
- 源泉徴収の対象かどうかを最後に確認する

これだけです。プログラムは1行もありません。毎回チャットに打ち込んでいた注意書きを、AIの定位置に置いておくだけで、以後は指示しなくても反映されます。

チャットに打ち込む指示文、いわゆるプロンプトとの違いは3つあります。第一に、毎回打たなくてよいこと。第二に、ファイルなのでチームで共有できること。第三に、いつ誰がどこを直したか履歴が残り、育てていけることです。プロンプトが個人の口頭指示だとすれば、スキルは組織の文書化されたマニュアルです。この違いは、使う人数が増えるほど効いてきます。

競合2社のツールで、同じルールが動く意味

今回の公開でもうひとつ見逃せないのは、Claude CodeとCodexの両対応という点です。AnthropicとOpenAIは競合関係にあります。その2社のツールで、同じルールファイルがそのまま機能する。これは、スキルが特定ツールの独自機能ではなく、業界をまたぐ共通の入れ物になりつつあることを示しています。

Word文書を例にすると分かりやすいと思います。どのメーカーのパソコンでも、どの文書ソフトでも、Word形式のファイルはだいたい開けます。だから私たちは安心して文書を蓄積できます。スキルも同じ状態に近づいています。テキストファイルにルールを書いておけば、使うAIツールが変わっても読ませ方を少し調整するだけで済む。書いたルールは、ツールを乗り換えても腐らない資産になります。

これは経営判断に直結する話です。AIツールの選定で悩む経営者は多く、選んだツールが1年後に主流でなくなるリスクを恐れて導入自体を先送りするケースをよく見ます。しかしルールの明文化という中心の作業がツールに依存しないなら、先送りする理由は薄れます。どのツールを選んでも、社内ルールの言語化は無駄になりません。むしろ早く始めた会社ほど、蓄積したルールの厚みで差がつきます。ツール選びは後から変えられますが、1年分のルールの蓄積は後から買えないからです。

マニュアルが、実行される文書に変わる

ここまでを非エンジニアの目線でまとめ直すと、起きているのはマニュアルの性質の変化です。

従来のマニュアルには宿命的な弱点がありました。人が読むものである以上、読まれなければ効果ゼロで、実際ほとんど読まれません。作った瞬間から陳腐化が始まり、更新も滞ります。棚の中で眠っている業務マニュアルに心当たりのある方は多いでしょう。

スキル化されたマニュアルは違います。読む主体がAIなので、読み飛ばしや読み忘れがありません。置いた瞬間から、チーム全員のAIの挙動が変わります。マニュアルが、読まれるのを待つ文書から、書いた瞬間に実行される文書に変わるのです。

この変化がいちばん効くのは、属人化に悩む会社です。従業員10人から100人規模の会社では、経理はあの人しか分からない、あの顧客対応はあの人にしかできない、という状態が普通に存在します。ベテランの判断基準をスキルとして書き出せば、新人とAIの組み合わせがベテランの型で仕事を進められます。ベテラン本人の負担も減ります。毎回口頭で教える代わりに、月に1回スキルを見直せばよいからです。退職や休職で知見が丸ごと消えるリスクも小さくなります。ルールを書き出す作業はAI以前から重要でしたが、書いたものが即座に実行されるようになったことで、投資対効果が桁違いに上がりました。

業種別に見る使いどころ

抽象論では伝わりにくいので、具体的な場面を3つ描きます。

1つ目は、従業員50名の製造業で経理を2名で回しているケースです。この規模の経理には、勘定科目の振り分け、消費税区分の判断、月次締めのチェックといった、明文化されていない社内ルールが大量にあります。交際費は1人あたり5,000円を境に扱いを変える、部門コードは製造と販管で分ける、といった判断です。これをスキルに書き出しておけば、Claude Codeに経費データの仕分け下書きを頼んだとき、最初から自社ルールで処理された結果が出てきます。担当の1人が急に休んでも、もう1人とAIで月次が止まらない体制に近づきます。仕分けルールの言語化は面倒に見えますが、過去3か月分の仕訳データをAIに見せてルールの下書きを作らせれば、たたき台は半日で作れます。

2つ目は、所長とスタッフ3名の社労士事務所です。就業規則をチェックするときの観点、顧問先に送る案内文のトーン、法改正があったときの確認手順は、所長の頭の中に蓄積されています。スタッフがAIで顧問先向けの案内文を作ると、内容は正しくても言い回しが事務所の流儀と違い、所長の赤入れが毎回発生する。ここで、赤入れでよく直す点を20項目ほどスキルに書き出しておくと、スタッフのAIが最初から所長の基準で下書きを出すようになります。修正の往復が減った分、所長は判断が必要な相談業務に時間を回せます。士業は文書の型と表現の一貫性が信頼に直結する業種なので、スキル化の効果が特に出やすい領域です。

3つ目は、10人規模のマーケティング支援会社です。クライアントごとに、レポートの構成、使ってはいけない表現、数字の見せ方の約束事が異なります。A社向けは前月比と前年同月比を必ず並記する、B社では競合名を出さない、といった約束です。これらは担当者の頭の中にあるため、担当変更のたびに引き継ぎ漏れが起きます。クライアント別にスキルを1枚ずつ作っておけば、新しい担当者がAIでレポート草稿を作っても、最初からそのクライアントの約束事が守られた状態で出てきます。月初のレポート作成が集中する時期に、チェックにかかる時間が目に見えて減ります。

3つに共通するのは、AIに新しい能力を足しているのではなく、すでに社内にある判断基準を、AIが読める場所に移しているだけだという点です。特別な技術は使っていません。だからこそ、どの業種でも再現できます。

今日から作れる実践手順

では実際に何をすればよいか。プログラミング知識は不要です。次の5ステップで進めます。

第1に、よく直す指摘とよく聞かれる質問を10個書き出します。部下やAIの成果物に対して、また同じ指摘をしていると感じる項目がスキルの原材料です。ここが最も価値のある工程で、30分かけて紙に書き出すだけでかまいません。

第2に、書き出した項目を1つのテキストファイルにまとめます。こういう場面ではこうする、という形式の箇条書きで十分です。先ほどの請求書ルールの例のように、名前と説明を先頭に付けておくとAIが用途を認識しやすくなります。

第3に、AIの定位置に置きます。Claude Codeなら、作業フォルダの中の .claude/skills/ルール名/SKILL.md というファイルとして保存すれば自動で認識されます。ブラウザで使うClaude Coworkなら、プロジェクトの指示欄やナレッジに同じ内容を貼り付ければ、実質的に同じ効果が得られます。

第4に、1週間ほど実務で使い、AIの出力がルールとずれた箇所をファイルに追記します。最初の1枚は必ず不完全です。ずれを見つけるたびに1行足す運用にすると、1か月で驚くほど実用的なマニュアルに育ちます。

第5に、月1回チームで見直します。ルールが変わったのに文書が古いままという、従来のマニュアルの失敗をここで防ぎます。見直しといっても、今月AIの出力を直した点を持ち寄って反映するだけの15分の打ち合わせで足ります。

始め方として私が勧めるのは、会社全体のルールではなく、1つの業務に絞った1枚から作ることです。請求書だけ、週報だけ、といった小さな単位で成功体験を作り、横に広げる。最初の1枚は、完璧さより早さを優先してください。育てる前提の仕組みなので、6割の出来で置いてしまうのが正解です。

注意点とよくある誤解

運用にあたって、つまずきやすい点を4つ挙げます。

第一の誤解は、プログラミング知識が必要だというものです。ここまで見たとおり、実体は箇条書きのテキストファイルで、業務ルールを日本語で書ける人なら誰でも作れます。Tikalの公開事例がプログラミング題材だったために誤解されがちですが、形式そのものに技術の壁はありません。

第二の誤解は、一度書けば終わりだというものです。スキルは書いて終わりの文書ではなく、運用で育てる仕組みです。放置すれば従来のマニュアルと同じ末路をたどります。追記の習慣と月1回の見直しまで含めて導入だと考えてください。

第三の誤解は、書けば書くほど賢くなるというものです。1つのファイルに何十ページも詰め込むと、AIは重要な指示を見落としやすくなります。目安は1スキル1業務。長くなってきたら、請求書ルールと経費ルールを分ける、というように業務単位で分割します。

最後に、これは誤解ではなく実務上の注意です。顧客名、取引単価、個人情報といった機密をスキルに書く場合は、置き場所に気を配ってください。社外に公開されるリポジトリや、共有範囲の広いフォルダに置くのは避け、社内限定の場所で管理します。また、スキルを整備してもAIが間違えなくなるわけではありません。請求書の発行や顧客への送信のような外に出る仕事は、必ず人が最終確認する体制を残してください。スキルは品質のばらつきを減らす仕組みであって、確認を省く仕組みではありません。

まとめ: ルールを言語化できる会社から伸びる

Tikalの公開事例が示したのは、チームのルールをAIに継がせる共通形式が、ツールの垣根を越えて定着し始めたという流れです。コーディング標準は最初の題材にすぎず、同じ器に経理のルールも、文書の型も、顧客ごとの約束事も載せられます。

AI活用の成果は、これからますますAIの性能差ではなく、自社のルールをどれだけ言語化できているかで決まるようになります。性能は各社横並びで進化し、誰でも同じものを使えます。差がつくのは、そこに載せる自社固有の判断基準の厚みです。そしてその蓄積は、今日、よく直す指摘を10個書き出すことから始められます。

自社のどの業務からスキル化すべきか、どんなルールを書き出せば効果が出るのか。判断に迷う場合は、Claude Worksの無料30分相談で、業種と体制に合わせた最初の1枚の作り方を一緒に整理します。無料30分相談はこちらからお申し込みください。