非エンジニアと小規模事業者は、この講座のどこだけ使えばいいか｜捨てる部分と、明日から使う部分

「35万人が受けた講座」と聞いても、従業員が3人の会社には遠い話に聞こえます。事務所のパソコンは事務用の3台、コードなんて書いたことがない。そういう現場に5日分の技術講座を丸ごと持ってきても、消化できません。

ただ、あの5日間には、コードを書かん人にこそ効く部分がはっきり混ざっとります。しかもそれは派手なところではなく、真ん中あたりの地味な回に埋まっています。この記事では、取る部分と捨てる部分を仕分けして、最初の1件を選ぶところまで持っていきます。

Day1からDay3を取り、Day4は考え方だけ、Day5は読むだけでいい

先に答えを出します。

日程	内容	非エンジニア・小規模事業者の扱い
Day1	バイブコーディングと開発環境	取る。ただし環境構築より「注文の仕方」を持ち帰る
Day2	MCPで外の道具につなぐ	取る。仕組みは概念だけ、使うのは既製のものだけ
Day3	エージェントスキル（SKILL.md）	一番取る。ここが本命
Day4	セキュリティと評価、人の承認	考え方だけ取る。設計の作法として頭に入れる
Day5	仕様駆動開発と本番デプロイ	読むだけ。手を動かすのは後回しでよい

なぜこの線引きになるか。ひとことで言えば、Day1からDay3は「自分の仕事の手順を、機械に渡せる形へ書き直す」話で、Day4とDay5は「その仕組みを他人に使わせても壊れないようにする」話だからです。

社内の数人で使う道具に、他人へ使わせる前提の重装備はいりません。逆に、手順を書き直す力は会社の規模に関係なく効きます。むしろ小さい会社のほうが、手順書がどこにもなくて全部ベテランの頭の中にある状態なので、効き方が大きい。

各Dayの具体的な中身（ホワイトペーパー・ポッドキャスト・コードラボの中身）は、Day1からDay5の解説記事にまとめてあります。この記事では、その中から「うちの規模なら、ここだけ」という絞り込みに専念します。

この記事で分かること

• 5日間のどこを受け、どこを飛ばせばよいかの判断
• コードを書かん人が持ち帰るべき3つの考え方
• 最初に任せる業務の選び方と、向かない業務の見分け方
• 導入の順番と、3週間で続けるかやめるかを決める方法
• 会員限定部分：そのまま真似できるSKILL.mdの記入例と、業務選定ワークシート

「全部やる」を目指した人が、だいたい途中で消える

仕分けの話をすると、「せっかくなら全部やったほうがいいのでは」と必ず言われます。気持ちは分かります。ただ、わしはここで一度足を止めてほしい。

理由は3つあります。

ひとつ目は時間です。あの講座は1日あたり、ポッドキャストと解説、ホワイトペーパー、コードラボで構成されています。まじめにやると1日2時間から3時間。5日で十数時間になります。本業の合間にこれを確保するのは、社長が現場も回しとる会社では現実的ではありません。

ふたつ目は前提の差です。Day1の入口で、開発環境のインストール、APIキーの発行、ターミナルでのコマンド実行が出てきます。調べればできる範囲ですが、初めてなら半日仕事です。そしてこの半日は、あなたの仕事の役に直接は立ちません。

みっつ目は目的のズレです。Day5でやる本番デプロイは、「作った道具を、社外や大勢の社員へ安定して使わせる」ための工程です。事務所で自分と経理担当の2人が使う道具に、この工程はいりません。ここへ時間を使うと、肝心の「何を任せるか」を考える時間がなくなります。

登録者・提出数の規模感は1本目の記事にまとめてありますが、走り切るのはそれなりに重い、というだけの話です。走り切らなかった大多数の中にも、途中まででちゃんと持ち帰った人はおります。わしらが狙うのは、そこです。

捨てていい部分と、その理由

気持ちよく捨てるために、理由を添えておきます。

修了バッジと最終課題は、もう追わなくていい

最終課題の提出は締め切られ、バッジと証明書はキャップストーンに参加した人へ配布される仕組みでした。今から自己ペースで学んでも、この2つは手に入りません。締切や配布条件の詳しい経緯は1本目の記事にまとめてあるので、ここでは繰り返しません。

残念な話に見えて、実はありがたい話でもあります。締切がないので、自分の業務に関係のある日だけ拾って、関係のない日は飛ばせる。提出物のために体裁を整える必要もありません。

Day5の本番デプロイは、今のあなたの仕事ではない

Day5ではエージェントを本番環境へ載せる話が出てきて、ハンズオンを最後まで通すには課金アカウントが必要になります（具体的な手順はDay1からDay5の解説記事のDay5部分で紹介した通りです）。

小規模事業者がここで手を動かす必要はない、とわしは考えとります。理由は単純で、本番デプロイが必要になるのは「作った道具が業務で毎日回るようになってから」です。まだ何も作っとらん段階で置き場所の議論をしても、時間だけが減ります。

ただし読むのは価値があります。Day5には「仕様を先に書いてから作らせる」という考え方が出てきて、これは道具作りの成功率をはっきり上げます。手は動かさず、考え方だけ持ち帰ってください。

英語の細部は、骨だけ取ればいい

教材は英語です。全部を精読しようとすると、そこで力尽きます。

ポッドキャストとホワイトペーパーは、翻訳を通して見出しと図と結論だけ追う。分からん単語は飛ばす。この読み方で十分です。

「エージェントを自分で作る」という言い方も、いったん捨てる

これは講座の内容ではなく、受け取り方の話です。

「AIエージェントを作る」と言うと、どうしても大きな話に聞こえます。実際にやることは、既にあるAIへ手順書を渡して、決まった仕事を毎回同じ品質でやらせることです。ゼロから何かを発明する話ではない。ここを取り違えると、最初の一歩が不必要に重くなります。

コードを書かん人が持ち帰る3つ

さて、取る側の話です。

1｜「作り方」ではなく「注文の仕方」を覚える（Day1）

バイブコーディングというのは、要するに「作り方を指示する」から「何が欲しいかを伝える」への移動です。

これは外注に慣れとる事業者なら、肌感覚で分かる話だと思います。腕のいい業者へ「この伝票を、この順で処理してほしい。ここだけは絶対に間違えたらあかん」と伝えるのと同じ。逆に指示が「よろしく」だけだと、腕のいい業者でもズレたものが上がってきます。

だからDay1で持ち帰るのは、コマンドの打ち方ではありません。依頼文の解像度を上げる、という一点です。

具体的には、頼むときに次の4つを必ず書きます。何を渡すか（入力）、何を返してほしいか（出力）、絶対に守ること（禁止事項）、判断に迷ったらどうするか（例外の扱い）。この4つを書くだけで、返ってくるものが変わります。

2｜手順書をAIへ渡す、という発想（Day3）

わしがこの講座で一番効くと思っとるのは、Day3のエージェントスキルです。

SKILL.mdという名前のファイルへやり方を書いて渡しておくと、AIはそれを読んで手順どおりに動きます。毎回同じ説明をしなくてよくなる、という仕組みです。

なぜこれが非エンジニアの本命かというと、中身がただの日本語の手順書だからです。プログラムではありません。「経費申請が届いたら、まず金額を見る。100ドル未満は自動で処理していい。100ドル以上は、内容を整理したうえで必ず人に確認してもらう」。こういう文章を書く作業です。

そしてこれは、あなたの本業に一番近い作業でもあります。20年やってきた業務の勘所を言葉にできるのは、社内であなたか、ベテランの担当者だけです。外部のエンジニアには書けません。

正直に言うと、この手順書を書く作業そのものが、AIを使うかどうかに関係なく会社の資産になります。人が辞めたときに困らんようになる。AIエージェントは、その副産物として動きます。

3｜「ここで人間が止める」を先に決める（Day4）

Day4は本来、攻撃されない作り方や品質評価の話で、規模の大きいシステムを想定しています。ただ、ここに一箇所だけ、小さい会社へそのまま効くところがあります。

人間の承認を挟む設計です。

講座では実際に、経費申請の処理を例に「一定額を超えたら必ず人が確認する」という流れを組みます（具体的な作り方はDay1からDay5の解説記事のDay4部分で紹介しました）。この考え方だけは、規模に関係なく最初から入れるべきだとわしは思っとります。

お金が動く、社外へメールが出る、データが消える。この3つに触る手前には、必ず人間を立たせる。全自動にしないというのは、技術力がないからやるのではなく、まともな設計だからやることです。

覚える専門用語は、3つだけでいい

講座には略語がたくさん出てきますが、実務で使うのは次の3つで足ります。

スキル AIへ渡す手順書のことです。ファイル名はSKILL.md。中身は日本語の箇条書きで構いません。「新人へ渡す作業マニュアル」と考えてください。

MCP AIが外の道具を触るための共通の差し込み口です。会計ソフトやファイル置き場など、外のものを触らせたいときに使います。大事なのは、これを自分で作る必要はほぼないことです。世の中に出回っとる既製のものをつなぐだけでいい。

仕様 作り始める前に、完成の条件を文章で書いたものです。「経費申請10件を渡したら、100ドル以上のものだけ確認待ちの一覧で返る」。これが仕様です。手順書は「やり方」、仕様は「できあがりの条件」です。

うちの規模でやるなら、この順番

考え方の話が続いたので、手順へ落とします。

1. 業務を1つだけ選ぶ。週に1回以上発生し、判断の基準がだいたい決まっており、間違えても取り返しがつくもの
2. その業務の手順を、日本語で20行以内に書く。ここではまだAIへ書かせない
3. ブラウザのAIへ手順書を貼り付け、実データ1件で試す。動かんなら道具ではなく手順書を直す
4. 通るようになってから開発環境へ移し、3週間、かかった時間と間違いの回数を記録する

ステップ2でAIへ手順書を書かせない理由は、あなたの頭の中にあるものを出す工程だからです。AIが書いた一般論の手順書は、それらしく見えて、あなたの会社の例外が入っていません。使い始めてから全部やり直しになります。

ステップ3で先にブラウザを使う理由も同じです。環境構築で先に疲れると、肝心の手順書に手が回りません。ブラウザで通らんものは、環境を整えても通りません。

ステップ4の記録は、続けるかやめるかを数字で決めるためです。3週間分たまると判断できます。だめならやめてください。1件目でうまくいかんのは普通のことです。

同じ例で最後まで追う｜経費申請の承認を任せる

抽象論で終わらせたくないので、1件を通しで追います。講座のコードラボでも実際に扱われている業務として、経費申請の承認を選びました。

確認項目	この例での具体例	自分の業務へ置き換える欄
対象業務	届いた経費申請を確認し、承認する	＿＿＿＿
発生頻度	週2〜3回	＿＿＿＿
渡すもの（入力）	経費申請の内容（金額・用途・申請者）	＿＿＿＿
返してほしいもの（出力）	自動承認していい件と、確認が必要な件の一覧	＿＿＿＿
絶対に守ること	金額を勝手に丸めない。判断に迷ったら必ず人へ回す	＿＿＿＿
人が必ず止める場面	金額が一定額（例：100ドル）を超えるとき	＿＿＿＿
やらせないこと	承認の最終確定そのもの。振込・支払処理	＿＿＿＿
1件あたりの現状	手作業で15分	＿＿＿＿
3週間後に見る数字	所要時間、AIの間違い回数、人が直した内容	＿＿＿＿

この表が埋まったら、それがそのまま手順書の材料になります。逆に埋まらん欄があるなら、それは業務が固まっていないということなので、まだAIへ渡す段階ではありません。人が代わっても同じ結果になるかどうか、そこを先に整える必要があります。

向く業務と、向かない業務

最初の1件を間違えると、AI自体の評価まで下げてしまいます。見分け方を書いておきます。

向くのは、判断基準が言葉になる仕事です。突き合わせ、分類、下書き、要約、転記。これらは正解が確認できるので、失敗しても原因が分かります。

向かないのは3種類あります。ひとつは、最終判断が人の勘に寄っとる仕事。値付けや、取引先ごとの温度感を見た対応などです。もうひとつは、月に1回しか発生せん仕事。改善したかどうか判断するまでに半年かかります。最後は、間違えると取引先へ直接迷惑がかかる仕事。1件目からここへ入れる必要はありません。

候補としてよく挙がるのは、見積書の下書き作成、問い合わせメールの一次分類、経費申請の承認、日報や議事録の要約あたりです。

時間とお金の見積もり

先に分かっていたほうが決めやすいので、目安を書いておきます。

Day1からDay3を、翻訳を通して骨だけ拾う読み方で合計4時間から6時間。そこから自分の業務へ落とす作業に、別途3時間から4時間。夜に1時間ずつ確保するイメージで、1週間から10日です。

費用は、講座の教材、録画、ホワイトペーパー、Discordがすべて無料です。開発環境のAntigravityも個人利用は無料で使えます。この記事の方針どおりDay5を読むだけにするなら、講座に関する費用はゼロで済みます。実務で使い続ける段階になったら、使うAIの利用料が出てくる、という順番です。

よくあるつまずき

本番データから始めてしまう

最初の1件目に、実際の経費申請や顧客情報を渡さんでください。手順が固まる前のAIは素直に間違えます。過去案件のコピーか、架空のデータで練習してから本番へ移してください。取引先の名前や金額が入ったものを扱う場合は、そのAIサービスの入力データの取り扱い条件も先に確認しておく必要があります。

全自動を目標にしてしまう

「人が一切触らんようにしたい」と最初に言う人は、だいたい途中でやめます。理由は、9割うまくいっても、残り1割の例外処理が終わらんからです。8割を機械へ渡して、2割を人が見る。この形が一番長持ちします。

講座の完走を目標にしてしまう

Day5まで通したかどうかは、あなたの会社の利益と関係ありません。目標は「業務が1つ軽くなること」です。Day3で目的が果たせたなら、そこで止めていい。

複数の業務を同時に任せてしまう

うまくいきそうに見えると、つい2つ目3つ目へ手を伸ばします。そうすると、どれも中途半端に動いて、どこが原因で失敗したのか分からなくなります。1件が3週間回ってから次へ行ってください。

よくある質問

プログラミングがまったくできませんが、本当に大丈夫ですか

Day3までの考え方を持ち帰るだけなら大丈夫です。ただ、講座のコードラボを自分の手で動かすところまで行くなら、ターミナルの操作とAPIキーの扱いは避けられません。ここは半日覚悟してください。社内に多少パソコンに強い人がおるなら、その人と2人でやるのが一番早いです。

社内の誰にやらせるべきですか

業務を一番よく知っとる人です。パソコンに強い人ではありません。手順書を書くところが山場なので、業務の勘所を持っとる人が主役になります。技術の部分は、その人が詰まったところだけ手伝えば足ります。

今から受けても、修了バッジや証明書はもらえますか

もらえません。詳しい経緯は1本目の記事にまとめてあります。狙うのは証明書ではなく中身です。

講座を受けずに、この記事だけで始められますか

始められます。この記事とシリーズ1・2本目で、業務へ落とすのに必要な考え方は押さえてあります。講座は、その裏付けと、もう一段深い話を取りに行くときの資料として使ってください。

うまくいかなかったらどうしますか

やめてください。それも成果です。3週間の記録が残っとれば、「この業務は今のAIには向かん」という判断ができます。次の候補へ移る判断が早くなるので、無駄にはなりません。

そのまま真似できるSKILL.md記入例

Day3で作る手順書は、こういう形になります。「経費申請の承認」を例に、実際にコピーして使える形で書いておきます。ファイル名をSKILL.mdにして、フォルダへ置くだけです。

---
name: expense-approval-check
description: |
  経費申請の内容を確認し、100ドル未満は自動承認、100ドル以上は人へ確認を回す。
  経費申請のチェックや一覧化を頼まれたときに使う。
  Do NOT use for 実際の振込・支払処理や、承認そのものの最終確定。
---

## 確認する順番
1. 金額を確認する。通貨が不明な場合は必ず人に聞く。
2. 用途が業務に関係あるか確認する。私的な支出が疑われる場合は「要確認」に回す。
3. 申請者・金額・用途を一覧に整理する。

## 判定ルール
- 100ドル未満：自動で「承認候補」として一覧に載せる。
- 100ドル以上：「要確認」として、理由（高額のため）を添えて一覧に載せる。
- 金額や用途が不明瞭な場合：判断せず「要確認」に回す。

## 絶対に守ること
- 承認の最終確定は行わない。一覧を作るところまで。
- 金額を勝手に丸めたり、推測で埋めたりしない。
- 迷ったら必ず「要確認」側に倒す。

このdescriptionの書き方がポイントです。「いつ使うか」と「いつ使わないか」の両方を書いておくと、AIが勝手に発動したり、逆に必要なときに気づかなかったりする事故を防げます。あなたの業務に置き換えるときも、この4つの見出し（確認する順番／判定ルール／絶対に守ること）の構造だけ真似すれば、中身は自分の言葉で埋められます。

最初の1件を選ぶワークシート

紙かメモアプリにそのまま写して、埋めてみてください。

□ 対象業務：
□ 発生頻度（週に何回）：
□ 渡すもの（入力）：
□ 返してほしいもの（出力）：
□ 絶対に守ること：
□ 人が必ず止める場面：
□ AIにやらせないこと：
□ 1件あたりの現状（所要時間）：
□ 3週間後に見る数字（所要時間・間違いの回数・人が直した内容）：

全部埋まったら、その内容を先ほどのSKILL.mdの見出し構造（確認する順番／判定ルール／絶対に守ること）へ流し込むだけで、AIへ渡せる手順書が1本できあがります。

まとめ｜取るのは3日分、本命はDay3

1. Day1からDay3を取る。Day4は考え方だけ、Day5は読むだけにする
2. 本命はDay3の「手順書をAIへ渡す」。日本語で書く作業なので、コードが書けるかは関係ない
3. 最初の1件は小さく選び、人が止める場所を先に決めて、3週間記録しながら回す

わしがこの講座を通して一番強く思ったのは、AIエージェントの時代に価値が上がるのは「自分の仕事を言葉で説明できる人」だということです。これは技術の話ではありません。あなたが積んできた年数が、そのまま効きます。

講座を自分で確かめたい方は、講座の案内ページと、今から学べる自己ペース版から入れます。5日間の中身を日本語で先に把握したい方は、Day1からDay5の解説記事を読んでから入ると迷いません。

まずは、最初の1件を紙の上で決めてください。上のワークシートを埋めるだけで、AIへ渡せる手順書が1本できあがる形にしてあります。

AI大将の公式LINEでは、こうしたAI活用の実例を、小規模事業者や非エンジニアの実務で使える形に噛み砕いてお届けしています。興味を持たれた方は、覗いてみてください。