AIに毎日触っているのに、なぜか「使いこなせている」という感覚にならない時期が続いていませんか。質問しては答えをもらい、便利だなと思いつつ、自分の仕事そのものが楽になっている気はしないという感じです。手は動かしているのに、足元の作業環境はあまり変わっていない、そんな段階で止まっている人は多いはずです。
「AIを使いこなす」と言われても、正直どの状態を指しているのか分かりにくいですよね。ちょっと自分でも何ができたら使いこなせていると言えるのか整理してみました。つまり、目の前の質問に答えてもらうだけでなく、自分の仕事の前提をAIに渡せて、調査から記事化までの流れにAIが組み込まれた状態を指しているようです。難しく見えますが、最初に見るポイントは「自分の作業環境にAIが入っているか」だけです。
この記事では、ChatGPTを2年、Claude Codeを半年ほど触ってきた個人の体験談として、自分の作業環境にAIを組み込めるまでに丸3ヶ月かかった経緯と、その結果として立ち上がった現在のBePro作業環境を整理します。前記事のAIを使って見えた過去資料の正体｜25年分の蓄積は本当に資産だったのかで「過去の蓄積は今のままでは資産にならない」と気づいたところからの続編になります。
シリーズ前提として、AIとは何か・クラウドLLMとは・ローカルLLMとはという全体像をここまで整理してきました。本記事はその上で、では実際にどう自分の仕事環境に組み込んだかという現場側の話です。完成形を見せるのではなく、運用中の途中経過を共有する形で進めます。
AIエージェントで感じた仕事の変化
AIを使い始めて、仕事の感覚がじわじわ変わってきた感覚。ChatGPTやClaude Codeで目の前の作業が片付くのは便利ですが、自分の仕事環境そのものが変わるとは予想していなかった人も多いはずです。この章では、AIエージェントを実際に使った結果として、何が変わる感覚が出てきたかを整理します。
これまでのエンジニア仕事が変わる感覚
これまで自分でやっていた作業が、AIに任せられる範囲だと気付いた瞬間はありますか。AIに渡しても噛み合わなかった作業が、ある時から突然うまく回り始める段階を扱います。
最初のうちは、AIに何を渡しても「それっぽい一般論」しか返ってきませんでした。検索したほうが早い、というのが正直な感想だった時期もあります。ところがある時期から、自分の仕事の前提を伝えたうえで頼むと、噛み合った返事が返ってくるようになりました。AIが急に賢くなったのではなく、自分の渡し方が変わっただけだと後から分かりました。
その瞬間に、これまで自分でゼロから書いていた調査メモやたたき台が、AIにある程度任せられる範囲だと見えてきます。完全に任せるのではなく、たたき台までは任せて、最終判断は自分でやるという分担が見えてきた感覚です。
定年後に稼ぐ手段を確保したい危機感
会社員のままで定年まで安定だと言い切れる時代でしょうか。AIを学び始めた背景にある、自分の足で稼ぐ手段を確保したいという危機感を素直に書きます。
正直に言うと、AIに興味があったから始めたという面だけではありません。定年後にも自分で稼げる手段を一つは持っておきたいという危機感が下敷きにありました。会社の中の役割だけに依存していると、その役割がなくなった時に何も残らないのではないかという不安です。
AIは新しい技術として面白いだけではなく、個人で動ける範囲を広げてくれる手段にもなりそうだと感じました。だからこそ、単なる質問ツールで終わらせるのはもったいなく、自分の作業環境に組み込みたいと思うようになっていきました。
試行錯誤を始めた出発点
AIを仕事に入れたいと思っても、何から触ればよいのか正直わかりづらいですよね。自分が最初に何を試したか、何で止まったかという出発点の整理から始めます。
最初に手をつけたのは、ChatGPTに調査を依頼して、結果をメモにまとめてもらうという単純な使い方でした。出発点としては悪くないのですが、すぐに同じ前提を毎回説明する手間に気づきます。前回の話を覚えていないので、毎回ゼロから状況を伝える必要があり、説明の時間と本来やりたい作業の時間が逆転していました。
ここで「使い方そのものを設計し直さないと前に進めない」と気づいたのが、試行錯誤の出発点です。質問の仕方ではなく、AIに前提をどう持たせるかという話に切り替わった瞬間でもありました。
AIを知っていたことと使いこなすことの違い
ChatGPTは知っているのに、なぜ自分の仕事ではうまく使えないと感じるのでしょう。触っている時間と、実際に仕事環境に組み込めるかは別軸で、この章ではその差を体験ベースで言葉にします。
そもそもAIの使い方は人によって入口が違います。月額のChatGPTを触る人もいれば、APIで自前のツールから呼ぶ人もいて、ローカルで動かす人もいます。前提の整理としてChatGPT月額・APIとローカルLLM、何が違うのか：AIの使い方は3種類あるも合わせて読んでおくと、本記事の「役割分担」の話が入ってきやすくなります。
ChatGPT歴2年でも足りなかった理由
ChatGPTを2年使っていれば、もう十分使いこなせていると言えますか。触り続けることと、自分の仕事の前提を渡せるようになることの間にある差を整理します。
自分の場合、ChatGPTには2年ほど触れていました。質問ツールとしては慣れていて、文章を整える、要約する、英訳するといった単発の作業は問題なくこなせていました。それでも、自分の仕事環境に組み込めているかと言われると、はっきり違いました。
足りなかったのは、自分の仕事の前提をAIに渡す仕組みでした。質問のたびに状況を説明し直すので、毎回スタート地点に戻る感覚です。触っていた時間は長くても、AIから見ると「初めての相手」を相手にしているような状態が続いていたわけです。
Claude Code歴半年で見えてきた変化
Claude Code (AIコーディングエージェント) を半年使った結果、ChatGPTだけでは出てこなかった作業感が見えてきました。
「Claude Code」という言葉だけ見ても、何をするものか分かりにくいですよね。ちょっと自分でも整理してみると、Claude Codeはターミナル上で動くAIコーディングエージェントで、コードを読んで、書いて、ファイルを編集してくれるツールです。難しく見えますが、最初に見るポイントは「ChatGPTがチャット欄の中で答えるのに対し、Claude Codeは実際にファイルを触ってくれる」という違いだけです。
半年使ってみて、ChatGPTでは得られなかった作業感が出てきました。具体的には、記事原稿の書き直しや、設定ファイルの整理など、ファイル単位の作業を任せられるようになった感覚です。チャット欄で答えだけもらう状態から、実際に手を動かしてくれる相手がいる状態への変化です。
仕事環境に組み込むまでにかかった3ヶ月
AIを試し始めてから、ちょうど良い使い方が見つかるまで、どれくらいかかると思いますか。丸3ヶ月という期間が、AIを学ぶ時間ではなく仕事環境に組み込む時間として必要だった経緯を整理します。
丸3ヶ月という期間は、AIの操作を覚える時間というよりは、自分の作業環境にどう組み込むかを試し続けた時間でした。何を任せて何を残すか、どの記憶をどこに置くか、どの順序で動かすかという設計を何度もやり直した期間です。
この3ヶ月は個人の体験談で、誰にでも同じ期間で同じ結果が出るとは思っていません。ただ、AIの使い方を「学ぶ」のではなく「組み込む」と捉えると、手応えが変わってくるという感覚は共有できる気がします。
以前の作業環境で起きていたこと
AIを入れる前、自分の作業環境にどんなボトルネックがあったのか・・・。以前の作業環境で起きていた「調査から記事化まで全部人間が抱える」状態を、まず棚卸ししておきます。
過去資料が抱え込みの原因になっていた点については、前記事AIを使って見えた過去資料の正体｜25年分の蓄積は本当に資産だったのかでも触れています。本記事ではその続きとして、現在作業側で起きていたことを整理します。
人間が調査から記事化まで抱えていた状態
調査・整理・記事化・公開準備をすべて自分でやってきたとき、何時間あっても足りない感覚。以前の作業環境で起きていた、人間が全工程を抱える状態の輪郭を整理します。
以前の作業環境では、調査も、整理も、記事のたたき台作りも、最終仕上げも、すべて人間側で抱えていました。AIを使っていても、出力をそのまま使えることは少なく、ほぼ自分で書き直していました。実質的にはAI抜きの作業時間と変わらないか、確認の手間が増えた分だけ余計に時間を使っていたほどです。
抱え込みの状態が続くと、調査までで体力が切れて記事化まで進まないという日が増えます。AIを使っているはずなのに、自分のキャパが上限のままで、出せる本数が伸びないという状態でした。
過去資料と現在作業が分断されていた問題
過去の調査と今の作業が、別々のフォルダにバラバラに残っていることはありませんか。過去資料と現在作業が分断されていて、自分の蓄積を活かせなかった状態を扱います。
過去資料は資料で別フォルダ、今の作業メモはまた別の場所、AIに渡す前提はチャット欄、というふうに置き場がバラバラでした。同じテーマを扱っていても、参照先が散らばっていて、自分でも全体像が掴めなくなる感覚があります。
この状態だと、AIに前提を渡そうとしても、まずどの資料を見せるかという判断から始めることになります。資料を選び直す手間で疲れて、結局その日は何も書けずに終わるということが何度もありました。
AIに前提を毎回説明していた非効率
AIに質問するたびに、毎回同じ前提を最初から説明することにうんざりしますよね。AIに毎回同じ前提を説明していた非効率を、具体的な場面で整理します。
「うちの読者層はこういう人で」「シリーズの位置づけはこうで」「使っているツールはこれで」と、毎回最初から説明していました。AIにとっては毎回が初対面なので仕方ないのですが、説明し終わるころには本題に入る気力が削れている、というのが正直なところでした。
この非効率を見て、説明をやめるのではなく、説明を「一箇所にまとめて全AIから読みに行く形」に変えれば良いのではないかと考えるようになります。これが後のcc-wiki構想につながっていきました。
AI中心へ変わった現在の作業環境
AIを中心に置く作業環境と聞くと、自分とは縁がない構成に見えていませんか。ここでは現在のBePro作業環境を、どのAIが何を担っているかという役割分担で整理します。
ChatGPTが担う戦略判断と壁打ち
ChatGPTを質問ツールだけで使い続けて、もう少し戦略的な相談相手にできないかと感じることが多々ありました。ChatGPTを戦略判断・方針整理・壁打ち相手として使う役割を本記事の構成上整理します。
現在の作業環境では、ChatGPTを「方針を決める前の壁打ち相手」として使っています。たとえばどのテーマで記事を書くか、シリーズの並び順をどうするか、受注導線をどう設計するかといった、判断の前段で考えを整理する場面です。
ファイルを触ったり、コードを書いたりはChatGPTには任せません。あくまで頭の中の整理と、選択肢の洗い出し、その判断材料の言語化までを担当してもらう、という線引きにしています。
Claude Codeが担う記事作成と実装修正
Claude Codeに何を任せれば自分が楽になるか、線引きに迷ってしまいますよね。Claude Code (AIコーディングエージェント) を記事作成・実装修正の担当として置く具体的な使い方を扱います。
Claude Codeには、記事原稿の作成と、設定ファイル・スクリプトの修正を任せています。たたき台の生成、見出しの整理、過去記事との内部リンク反映、frontmatterの調整など、ファイル単位で完結する作業を担当範囲にしています。
Claude Codeをどこまで自動で動かしてよいか、どの作業を分けるかという話は、料金面でも整理が進んでいる領域です。背景としてはClaude Codeの自動実行に料金分離｜Agent SDKクレジットで何が変わるのかも参考になります。本記事の範囲では、Claude Codeはあくまで「ファイルを触ってくれる作業担当」として位置づけている、という線引きで止めておきます。
cc-wikiが記憶の本体になる構成
複数のAIに同じ前提を毎回渡すことに、もう疲れていませんか。「cc-wiki」という言葉だけ見ても、何のことか分かりにくいですよね。ここではまず「どのAIも同じ前提を参照できる仕事の覚書置き場」と考えてください。すべてのAIが同じ前提を読みに行く本体になる構成を本記事で示します。
cc-wikiは、調査結果・判断材料・記事設計・運用ルールを一箇所にまとめたMarkdown中心の置き場です。ChatGPTにもClaude Codeにも、必要に応じて同じcc-wikiの該当ページを参照させることで、毎回前提を説明し直す状態から抜けられました。
AIごとに別の記憶を持たせるのではなく、本体は一つだけ持ち、AIはそこを読みに来るという構造です。記憶を「AI側」ではなく「自分側」に置いておく感覚で、ここがBePro作業環境の中心になっています。
n8nとHermesAgent・ローカルLLMの補助役
自動化ツールのn8nや、ローカルで動くAIに役割を持たせる場面が見えていますか。「n8n」「HermesAgent」「ローカルLLM」と聞くと身構える人も多いですよね。ここではまずn8nは定型処理を回す「自動化基盤」、HermesAgentとローカルLLMは手元で動く「補助的なAI」と考えてください。本記事では中心ではなく補助役の位置づけとして扱います。
n8nには、定型処理の自動実行を任せています。たとえば毎日決まった時間に走らせたい処理や、外部サービスとの連携処理を、画面上で繋いで動かす役割です。n8nを単独で主役にするのではなく、ChatGPTやClaude Codeの作業の前後に挟むつなぎとして使うイメージで、詳しい使い分けはAI自動化で作業者に戻らないためのn8nとAIエージェントの使い分けでも整理しています。
HermesAgentとローカルLLMは、手元のマシンで動かせるAIとして補助役に置いています。クラウドのChatGPTやClaude Codeに比べると賢さで差が出る場面はありますが、ちょっとした下処理や、外に出したくないデータを扱う場面で役に立ちます。なぜ主役ではなく補助役にしているかは、別記事個人開発でローカルLLMを主役にしなかった理由──クラウドLLMとの知能差・APIコストの誤解でも書いた通りで、本記事の作業環境でも同じ判断を採用しています。
cc-wikiを中心にした理由
AIごとに別の場所へ記憶を持たせると、情報の置き場所が分散します。必要な前提を探すたびに、ChatGPT、Claude Code、ローカルのメモ、過去資料を行き来することになり、作業の流れが崩れます。ここでは、なぜcc-wikiという1つの本体に記憶を集める構成にしたのかを整理します。
AIごとに記憶を分散させない考え方
ChatGPT・Claude・Geminiに同じことを覚えさせようとして、二度手間が起きた経験・・・。AIごとに記憶を分散させない方針を本記事で言葉にします。
AI側に記憶を持たせると、AIを乗り換えるたびに記憶が消える、別のAIには引き継げない、同じ説明を複数のAIに渡すことになる、といった面倒さが後から出てきがちです。AIは進化が早く、半年後には主役のAIが入れ替わっている可能性も普通にあります。
そこで、記憶を「AI側」ではなく「自分側のcc-wiki」に集める方針にしました。AIが変わっても、cc-wikiは残ります。AI側に書き込むのではなく、自分側に書いたものをAIから参照させる、という方向に逆転させた格好です。
過去資産と現在作業をつなげる役割
私は今まで過去の調査と今の作業を、別物として扱ってきました。cc-wikiが過去資産と現在作業をつなげるハブとして機能している役割を整理します。
cc-wikiは、過去の調査資料、現在進行中の作業メモ、判断材料、運用ルール、記事設計などを並列に置ける場所として作っています。過去のものをアーカイブして見えなくするのではなく、現在作業から地続きで参照できる場所にしておくのが要点です。
過去資料に手をつける必要があるときも、別フォルダを掘り起こすのではなく、cc-wikiの中で同じように扱えます。過去と現在の境目をなくして、AIに渡す前提として一括で扱える状態にしたところに、cc-wikiを中心に据えた狙いがあります。
すべてのAIが同じ前提を参照する意味
複数のAIに同じ前提を毎回説明していると、何が起きるか想像できますか。すべてのAIが同じ本体を読む構成にしたことで、回答が一般論から自分の仕事用に変わる意味を扱います。
すべてのAIが同じcc-wikiを参照する構成にすると、回答の前提が揃います。ChatGPTに聞いた話と、Claude Codeに頼んだ作業の方向性がズレる場面が減り、AIごとに違う方針を出されて混乱する事態を抑えられます。
AIから返ってくる内容が一般論から自分の仕事用に寄ってくるのも、同じ前提を読んでいるからです。AIを増やしても、本体は一つなので、扱う負担が線形に増えていかないという利点もあります。
AI中心の環境で変わった作業の流れ
調査から記事化、受注までの流れが、AIを入れる前と後でどう変わるのか。ここでは、調査→知識化→記事設計→記事化→受注導線という流れの中で、AIと人間の分担がどう動くかを示します。
調査から知識化までの流れ
調査結果を集めただけでは、AIが使える知識にはなりません。必要なのは、集めた素材をそのまま積むことではなく、あとからAIが読める形へ整理し直すことです。ここでは、調査素材をcc-wikiへ取り込み、記事設計や判断材料として使える状態に変える流れを具体的に扱います。
調査の段階では、外部記事や公式情報を読み込み、要点をメモにまとめます。ここまでは人間とAIの混在作業で、ChatGPTに要点を整理してもらう場面も含みます。集めただけだと「素材」のままで、AIに渡してもうまく使えません。
次に、その素材をcc-wiki側で「知識化」します。テーマごとに分けて、見出しを揃え、判断材料が分かる形に整える工程です。この知識化が終わると、AIが同じテーマの記事を書くときに、毎回ゼロから説明する必要がなくなります。
知識化から記事設計までの流れ
整理した知識を記事へ落とし込むタイミングが早すぎると、ただの調査メモになります。遅すぎると、どの記事で何を使うのか分からなくなります。ここでは、知識化済みのcc-wikiをもとに、記事の目的、読者の停止点、見出し構成へつなげる流れを整理します。
cc-wikiに知識化済みの素材が揃ったら、次は記事設計に進みます。記事のタイトル、対象読者、見出しの並び、受注導線の置き方を決める段階です。ここはChatGPTを壁打ち相手にしながら、最後は自分で決める流れにしています。
記事設計は記事化の半分くらいの重さがあると感じます。設計が固まっていれば記事化はかなり機械的に進められ、設計が曖昧なまま書き始めると途中で何度も止まるという経験則です。
記事化から受注導線までの流れ
記事を書いたあとに止まりやすいのが、読者をどこへ案内するかです。いきなり依頼を出すと営業色が強くなり、何も出さないと記事だけで終わります。ここでは、記事本文の中で読者の停止点を整理し、その先に仕様整理や相談導線を自然につなげる流れを扱います。
記事化の段階では、設計書をもとにClaude Codeにたたき台を書かせ、こちらで読み直して仕上げます。最後に、記事の末尾で受注導線を出します。記事の途中で営業色を強く出さず、本文の整理が終わった後で「相談したい人へ」という形で案内する方が、読者の負担にならない流れです。
受注導線は記事ごとに1ヶ所にまとめ、本文に過度に挟まない方針にしています。読者が読み終わって「自分でも整理してみたい」と感じた時に、自然に相談先が見える位置に置いておく、という考え方です。
まだ完成ではなく運用中の環境
AI中心の作業環境は、すべてを自動化した完成形ではありません。実際には、AIに任せる作業と、人間が確認する判断が混在しています。ここでは、まだ運用中の環境として、どこまでAIに任せて、どこから人間が見る必要があるのかを整理します。
すべてが自動化されたわけではない現実
AI中心の作業環境といっても、人間がほぼ介入しない状態ではありません。実際には、定型処理の一部は自動化できても、判断、確認、修正、公開前チェックは人間側に残ります。ここでは、何が自動化済みで、何がまだ人間判断として残っているのかを整理します。
実際には、すべてが自動化されているわけではありません。たたき台の生成、ファイル単位の修正、定型処理は任せられていますが、テーマ選び、構成判断、最終仕上げ、公開判断は自分で行っています。AIに任せる範囲と、自分が判断する範囲が分かれているだけで、人間がいなくなったわけではない状態です。
「AI中心」と表現していますが、内訳としては「AIが作業の中央にいる」という意味で、「AIだけで完結する」という意味ではありません。この線引きを曖昧にすると、過剰な期待や逆方向の失望が起きやすくなります。
人間に残る判断の部分
現場条件との整合、責任分界、最終承認をAIに丸投げできるでしょうか。人間に残る判断の部分を、AIを補助役として使う前提で言葉にします。
人間側に残しているのは、テーマ選びの最終決定、読者層との整合判断、表現の最終調整、公開可否の判断、受注導線の置き場所、責任の所在に関わる判断などです。AIに任せられる範囲が広がっても、責任の取り方そのものをAIに移すことはできません。
逆に言えば、責任の所在をはっきりさせておけば、その手前の作業はAIに任せられる範囲がかなり広いという感覚もあります。任せる範囲と残す範囲を意識して切り分けておくと、AIを補助役として安心して使えます。
それでも以前の環境には戻れない理由
AIを使った作業環境は、まだ不完全です。手戻りもありますし、人間が確認しないと危ない場面も残っています。それでも、調査、整理、記事設計、実装、自動化、記録をすべて人間だけで抱えていた以前の状態に戻すと、作業量も判断負荷も一気に増えます。ここでは、不完全でも以前の環境には戻れない理由を率直に整理します。
不完全で運用中の環境ですが、以前の環境に戻れるかと聞かれると、戻れる気がしません。同じ作業を全部人間が抱える状態に戻ると、調査だけで体力が切れていた感覚が思い出されます。AIがいる前提で動けるようになると、いない前提の作業ペースに体感が合わなくなります。
完成していなくても、運用しながら少しずつ良くしていける環境があるという安心感が、戻れない一番の理由かもしれません。完璧でなくても良いから、自分の作業環境にAIが入っている、という状態が大きいわけです。
まとめ
ここまでで、作業環境が変わるとはどういう感覚か、少し言葉になってきたでしょうか。最後に、AIは道具追加ではなく環境変化だったという気づきを、次に進む読者の入口に整理します。
AIは道具追加ではなく環境変化
AIを新しいツール1つの追加と捉えていると、何が変わるか見えづらくないでしょうか。道具を増やすのではなく、作業環境そのものが変わるという捉え方を最後に振り返ります。
AIを「新しい便利な道具」と捉えるだけだと、いつまで経っても作業環境は変わりません。道具が増えただけで、自分の動き方は同じだからです。AIを使いこなす感覚が出てくるのは、自分の動き方そのものをAIありの前提に組み替えた時です。
道具追加ではなく環境変化として扱えると、調査・知識化・記事設計・記事化・受注導線の流れごとに、何を任せて何を残すかを設計し直す視点が出てきます。便利な道具が一つ増えた話で終わらせない、ここが本記事の中心にある気づきです。
使いこなす感覚を得るまでにかかった3ヶ月
使いこなす感覚を得るまでに、どのくらい時間が必要だと感じましたか。丸3ヶ月という期間の意味を、もう一度言葉にして振り返ります。
丸3ヶ月という期間は、AIの操作方法を学ぶ時間ではなく、自分の作業環境にどう組み込むかを試し続ける時間でした。設計と運用を交互にやり直しながら、徐々に「これなら戻らずに済む」という形にまとまっていった期間です。
個人の体験談なので、誰でも3ヶ月で同じ結果になるとは限りません。ただ、「AIを学ぶ」より「AIを組み込む」と捉え直すと、時間の使い方が変わってくるという感覚はある程度共有できると思います。
次は個別のAI活用へ進む段階
ここまで整理すると、次に深掘りするテーマは自然に見えてきます。AIを仕事環境に組み込むうえで重要になるのは、AIに何を覚えさせ、どの前提を参照させるかです。本記事の次では、個別のAI活用テーマとして、LLMナレッジベースの考え方へ進みます。
本記事では「作業環境の全体像」を扱いましたが、次に進む段階としては個別のAI活用テーマがあります。特に本記事で何度か触れたcc-wikiの考え方は、もう少し深掘りすると「LLMナレッジベースとして過去の記憶を残す」というテーマにつながります。
次のステップとして、cc-wiki的な発想を仕組みとして捉え直す記事を用意しています。本記事で気づいた「記憶の本体を自分側に置く」という考え方を、具体的にどう設計するかという視点で続きを読んでみてください。
次に読む記事
本記事で得た「cc-wiki = 記憶の本体」という気づきを、もう一段具体的な仕組みとして捉え直したい場合は、次の記事に進んでください。AIに過去の前提を覚えさせ続けるための、Markdownベースのナレッジベースという考え方を扱っています。
