小さい会社が生成AI活用を始めるなら、最初にやるべきこと
小規模なサイト運営と個人開発で生成AIを使った経験から、全社戦略ではなく、毎週発生する小さな1作業から始める方法を実例付きで紹介します。
うにラボで生成AIを使い始めるとき、最初から全社向けのAI活用戦略や大きな仕組みを作ったわけではありません。
ブログの修正、コードのたたき台、Gitの差分確認、既存情報の整理など、その日に発生した小さな作業へ使うところから始めました。
実際に続いたのは、「AIで何ができるか」を広く考える方法ではなく、毎回面倒だった1作業を選び、人間が確認しながら繰り返す方法でした。
先に結論
小さい会社が生成AI活用を始めるなら、日常的に発生する作業を1つだけ選びます。
選ぶ条件は次の3つです。
- 毎週または毎月、同じような形で発生する
- 作業量は多いが、最終判断は人間ができる
- 入力資料と完成形を比較しやすい
最初からAIへ最終判断を任せません。集める、並べる、下書きを作る、差分を洗い出すところまで任せ、人間が事実と公開可否を確認します。
最初に任せたのは、大きな戦略ではなく作業の一部だった
このサイトと関連プロジェクトでは、AIを次のような作業に使っています。
- 既存ブログの構成整理と修正案
- Search Consoleの数値から改善候補を整理する作業
- Next.jsやPythonのコードのたたき台
- GitHubで確認する差分と変更対象の整理
- 公式FAQや既存データの分類
- 開発タスクと確認手順の整理
いずれも、AIだけで完了させる仕事ではありません。
元資料、変更前のコード、実際の検索データなど、比較できる材料があります。AIの出力が違えば、人間が指摘して直せます。
実例1：記事を増やす前に、実測値から既存ページを直した
SEO改善では、新しい記事案を大量に出すこともできます。
しかし実際に行ったのは、Search Consoleの数字を見て、すでに表示されている既存ページを直すことでした。
料金ページ/pricing-masterは、ある集計期間で次の状態でした。
- 表示回数：1,077回
- クリック：2回
- CTR：0.2%
- 平均掲載順位：9.4位
この数値から、新記事を増やすより、タイトル、H1、導線、検索語との言葉のずれを先に直すと判断しました。
Search Consoleの実測からSEO改善の優先順位を決めた記事には、実際のクエリと修正内容まで載せています。
AIは候補整理を助けられますが、「今どのページを直すか」は実測値を見て決めます。小さい会社では、このように対象を1ページへ絞る方が、作業も結果確認も明確になります。
実例2：誤情報をきっかけに、AIへ任せる範囲を狭めた
AIに記事の整理を任せると、自然な文章が速くできます。
一方、運営サイトでは「1,100円で6か月延長できる」という、公式情報で確認できない制度が記事に混ざりました。
確認のために公式FAQを102件保存し、実際に確認できた制度へ内容を修正しました。文章の一部だけではなく、存在しない制度を前提にした比較構成も直しています。
AIの誤情報を公式FAQ102件で確認した記事で、この失敗と修正内容を公開しています。
この経験から、最初のAI活用に、料金や契約条件の最終判断は選ばない方がよいと考えるようになりました。
代わりに、次のように分けます。
AIへ任せる部分：
- 確認候補を集める
- 情報を分類する
- 下書きを作る
- 矛盾しそうな箇所を洗い出す
人間が行う部分：
- 公式情報を開いて条件を読む
- 数字と対象者を確認する
- 公開してよい内容か判断する
- 最終文章を承認する
実例3：細かなコード修正に合わせて、Git運用を変えた
AI開発ツールを使うと、小さなコード修正とレビューを繰り返しやすくなります。
以前は、GitHubで差分を見るためにdevへpushしていました。しかしdevはAWS Amplifyにつながっていたため、レビューのたびに検証環境のデプロイが走っていました。
そこで、featureブランチを開発・レビュー、devを検証環境、mainを本番環境として分けました。
AmplifyとGitHubのレビュー運用を分けた記事で、変更前後の流れと実行している型チェック・ビルドを紹介しています。
これはAI活用のための大規模システムではありません。毎回発生していた「差分を見たいだけなのにデプロイされる」という小さな無駄を、作業単位で直した例です。
実例4：判断ではなく、確認の準備を仕組みにした
月次更新では、料理・パン・ケーキの画像を複数取り違えたことがあります。
画像は表示され、404にもならず、TypeScriptの型チェックとビルドも通ります。しかし、料理名と画像の組み合わせは間違っていました。
そこで、取得した素材を分類し、campaigns.jsonとmenus.jsonへ整理し、/admin/202603のような月別確認画面へ名前と画像を並べる仕組みを作りました。
画像の取り違えから確認専用画面を作った記事で書いたように、自動化したのは最終判断ではありません。人間が正誤を判断しやすい状態まで準備する部分です。
小さい会社の最初のAI活用も、この考え方と相性がよいです。
明日任せる1作業の決め方
最初の対象は、次の順番で決めます。
1. 毎週または毎月発生する作業を書く
たとえば、ブログ修正、問い合わせ返信の下書き、Gitの差分確認、資料の要点整理、月次データの分類です。
実際に繰り返している作業だけを書きます。「将来やるかもしれない仕事」は候補から外します。
2. 判断より作業量が多いものを1つ選ぶ
情報を集める、同じ形式へそろえる、下書きを作る、変更箇所を列挙するといった作業が候補です。
契約、料金、法的判断、公開可否のように、間違えたときの影響が大きい判断は最初の対象にしません。
3. 1個だけAIへ任せる
「サイト運営を改善して」ではなく、次のように範囲を限定します。
- この既存記事と一次情報を比較し、食い違いを列挙する
- このGit差分が、指定したファイル以外を変更していないか確認する
- この月のデータを、前月と同じ項目へ整理する
入力と期待する出力を具体的にします。
4. 出力を人間が確認する
AIが返した文章やコードを、元資料と照合します。
コードなら差分、型チェック、ビルド、必要に応じて公開画面まで確認します。文章なら数字、固有名詞、条件、出典を確認します。
5. 良かった指示と確認手順を残す
使えた指示だけでなく、どこを人間が確認したかも残します。
次回は同じ指示と確認手順から始めます。これを繰り返して初めて、AI活用が単発の試用から日常業務へ変わります。
実測できていない効果は書かない
AI導入前後で、各作業が何分短くなったかを比較できる記録は、現時点では確認できていません。
確認できるのは、FAQ102件を使った誤情報修正、Search Consoleの実測に基づくSEO修正、GitとAmplifyの運用変更、月別確認画面の実装です。
成果を大きく見せるより、次回から同じ手順を使えるかを先に確認します。
まとめ
小さい会社が生成AI活用を始めるなら、最初から全社導入や大きな仕組みを作る必要はありません。
毎週発生する作業を書き、判断より作業量が多いものを1つ選び、AIへ任せ、人間が確認し、使えた指示を残します。
うにラボで続いたのも、ブログ、SEO、Gitレビュー、コード修正、情報整理といった小さな作業から始める方法でした。
明日任せる仕事は、「AI活用戦略を考えること」ではなく、次にまた発生する1作業の準備を手伝ってもらうことです。
