ども！サブエージェントを43本まで増やして、メンテが終わらなくなった龍ちゃんです。 エージェント、増えますよね。観点を思いつくたびに1本作れるので、止まらないんですよ。 結論から言うと、 agent から観点を抜きました 。何を見るかは別のファイルに置いて、呼ぶ側からそのファイルの場所を渡す。agent 側には道具と権限とモデルだけを残しました。今日はその話をします。 サブエージェントが大量に繁殖、管理が大変に 観点を思いつくたびに1本作る、をやっていました。技術的な正確さ、文体、SEO、企業リスク、論理、読者目線。増えるのは自然なんですよね。観点は次々思いつくし、1本作るコストは低いので。1体に欲張って失敗して 3エージェントに分けた話 も書いてます。分けたのは正解でした。今日の話は、分ける先が agent から観点ファイルに変わったという続きです。 先に断っておくと、ここで言う「増える」は実行中にサブエージェントが再帰的に呼ばれる方の話ではないです。 .claude/agents/ に定義ファイルが積み上がる方ですね。 しんどいのはその後です。40本を超えたあたりから、どれがどういう状態なのか分からなくなりました。直さないといけない箇所に見当はついているのに、1本ずつ開いて直す作業が誰にも回されないまま残るわけですね。 で、6月に Claude Code スキルの誤発火を防ぐ「ルーター集約」設計 という記事を書いています。スキルを個別に発火させるのをやめて、1つのルーターに束ねて発火条件を揃えた話です。あれは効きました。狙ったものがちゃんと発火するようになったし、記事の中で「メンテも楽になりました」とも書いてます。関連ファイルが文脈で1か所にまとまったので、どれを見ればいいか迷わなくなったのは今でも事実です。 ただ、当時こうも書いていました。 観点を足したいときは references を 1 ファイル直すだけです。SKILL.md にも agent 本体にもベタ書きしないから、常時のコンテキストは増えないし、ナレッジの管理も一箇所で済むんですよね。 書いた本人としては本気だったんですけど、実態はそうなりませんでした。監査したら、references に置いたはずの語彙リストが agent 本体にもほぼ逐語で35行コピーされていたんですよね。 理由は、どっちに何を書くかを決めていなかったことです。「ベタ書きしない」は方針ではあるけど、境界ではないんですよ。書くたびに「これは agent の本文なのか、references なのか」を考えることになって、判断がぶれた分だけ両方に書かれる。そして直すときにも同じ判断が発生します。観点を1つ直したいだけなのに、agent を開くのか references を開くのかを先に決めないといけない。この判断がずっと乗っかっているのが、メンテが終わらない理由でした。 しかも本数は減らないんですよ。観点を1つ足すには、ルーターの振り分け表に1行足して、agent を1本作って、references も直す。観点1つの追加で3ファイル編集でした。ルーターは呼び出し口を1つにしてくれますが、呼ばれる側の数はそのままなんですよね。 観点を尖らせたいのに、下手に手を入れることができない 文脈で束ねた結果、同じ agent が別の場所でも活躍するようになったんですよね。 たとえばセキュリティ観点のレビュー agent を1体作って、API の実装レビューで使い始めたとします。動くと分かったら、インフラの設定レビューでも呼びたくなるんですよ。観点は同じなので当然そうなるし、この時点では嬉しいだけです。 うちでそうなったのが論理チェックの1体でした。ブログでもプレゼンでもセミナーでも提案書でも「論理」は要るので、この1体が持ち場を増やしていく。git を遡って数えたら、こうなってました。 時点 論理チェックを呼んでいたルーターの数 ルーター集約の直前 1対1（観点ごとにスキルがあった） 集約した直後 3 レビュー系を整理した後 5 移行の直前 6 2つ以上のルーターから呼ばれている agent は、43本中14本ありました。使い回せる状態になったのは、ある意味では成果です。ただ、そこで観点を尖らせようとするとルーター側で修正を入れても、agent側の定義と喧嘩したりとにかく大変なんですね。 プレゼンのレビューを鋭くしたくて「スライド1枚に主張が1つか」を1行足すと、ブログのレビューでスライドを探すみたいな感じです。ブログには要らない観点が同居する。隣に余計なものが入った状態ですね。じゃあ混ざらないように、どっちでも通る書き方に薄めると、今度は指摘が当たり障りのないものになります。尖らせると混ざるし、混ざらないようにすると鈍る。 コードの共通化とまったく同じ形です。共通関数にまとめると呼び出し元を全部気にしないといけなくて、コピペすると直し漏れる。あれですね。結局やりたかったのは、agent は使い回したまま観点だけ分けることでした。 ちなみにこれ、43本ないと起きない話じゃないです。 2つ目の呼び出し元が同じ観点を呼びたくなった時点で始まります 。うちは43本まで放置したから派手に見えてますけど、5本でも同じ形で詰まりますね。 agent から観点を抜いて、ファイルに追い出しました やったことは1つです。 agent の責務と観点ファイルの責務を切り分けました。 この agent は10本のルーターから呼ばれるので、持たせたのは実行環境と返し方だけにしました。どのモデルで動くか、どの道具を持つか、どの権限か、結果をどう返すか。観点ファイルが持つのは何を見るか、どう掃くか、どう深刻度をつけるか。呼ぶ側は観点ファイルのパスを渡すだけで、中身は渡しません。 観点を持たないので、こうなった agent のことを僕は器と呼んでます。中身が空の筐体だけ残した、という意味ですね。以下そう書きますね。 境界を決めたので、書くときも直すときも迷わなくなりました。観点を直したいなら観点ファイルを開く。道具や権限を変えたいなら agent を開く。それだけです。一般化するのは器だけにして、観点は尖らせたまま外に置く、という形ですね。 器の実物がこれです。全部で42行で、要点だけ抜くとこうなります。 --- name: ro-sonnet description: >- router skill から「lens/persona ファイルのパス + 対象ファイルのパス」を委譲プロンプトで 受け取り、その定義だけに従って読み取り専用で文書を検査する汎用ワーカー（sonnet）。 tools: [Read, Grep, Glob] model: sonnet --- あなたは渡された lens / persona ファイルの定義だけに従って動く汎用ワーカーです。 自分の判断で観点を足さない。定義に無いことは見ない。 ## 手順 1. 委譲プロンプトから lens/persona ファイルのパスを取得して Read する 2. lens の `## ナレッジベース` に参照パスがあれば、それらを Read する 3. lens の `## 入力` に従って対象ファイルを Read する 4. lens の `## 走査手順` に従って掃く。判定は `## 検出対象` のみで行う 5. lens の `## 出力形式` で返す 観点はどこにも書いてません。「論理」も「文体」も「SEO」も出てこない。中身は別のファイルが持っていて、ルーターが起動時にそのパスを渡します。 ちなみに名前も実行環境だけでできてます。 ro- は read only、 rw- は Write を持つ側で、後ろはモデルか足した道具です（ ro-sonnet は読み取りだけの sonnet）。 logic-reviewer だった頃と違って、観点は名前にも入ってません。 コードに出てくる lens が、その観点ファイルです。うちのリポでファイル名をそう付けているだけなので、以下は観点ファイルと書きますね。人格を持つものだけ persona- を頭に付けて分けていて、厳しめレビューの persona-harsh.md がそれです。作りは同じで、名前だけ変えてます。 観点ファイルの中身は、こういう節でできてます。 ## 入力 ← 何を読むか ## 検出対象 ← 何を見つけたら指摘するか ## 走査手順 ← どういう順で掃くか ## 判定軸 ← 過剰検出をどこで止めるか ## 出力形式 ← どう返すか 「論理だけ見て」と言われたらルーターが lens-logic.md のパスを渡すし、「厳しめで」なら persona-harsh.md を渡す。器は同じです。ここはルータの定義としてSKILLの中で管理することができます。 面白いのは、使い回すのをやめたわけじゃないところですね。いまこの器は10本のルーターから呼ばれてます。前は6本で混ざっていたのに、10本に増えたのに混ざらない。使い回していたものが「観点を持つ1体」から「観点を持たない器」に変わっただけです。（なのでリモート端末みたいな使い方をしていますね。その都度インストールするみたいな） 観点そのものの中身は記事を分けて書いていて、 書く前レビューのエージェント とか 文体を直すエージェント あたりに置いてあります。今日は中身ではなく置き場の話ですね。 何が良くなったか 3つあります。 いちばん効いたのは、agent をメンテしなくなったことです。移行してから18日で .claude/agents/ を触ったコミットは5つだけでした。しかもどれも、観点を足したからではないんですよね。観点は増えても agent は増えない。 次に、新しい観点の試し方が変わりました。前は「この観点いいな」と思ったら agent を新設するところから始まっていて、それが地味に重い。いまはチャットでそのまま観点を投げて試して、使えそうなら観点ファイルに上げるだけです。ファイルは移行した時点で41枚、いまは46枚に増えました。増やす方向が安くなったのがうれしいところですね。 3つめは budget です。agent の description は起動時に常時載るので、本数がそのまま重さになるんですよね。実測では 7,318字 が 1,604字 になりました。1本あたりの長さはほとんど変えていないので、減ったぶんは全部「本数が消えたこと」から来ています。無駄にトークンを食い散らかしている感覚もなくなりました。ただ実行時のトークンは測っていないので、そこは体感ですね。言い切れるのは起動時に常時載る量の話だけにしておきます。 その分 SKILL ファイルは大きくなりましたが、 段階的開示 （progressive disclosure）が効きます。常時載るのは description だけで、SKILL.md の本体は発火したとき、 references/ は必要になったときにしか読まれないんですよね。 この形を採用するなら1つ気をつけてください。 器は使い回す前提なので、器を1本直すと、その器を呼んでいる全部のルーターに同時に響きます。 model を変える、道具を1つ足す、手順を1行直す。どれも全部に効きます。観点が混ざる問題が消えたわけじゃなくて、響く範囲を「観点を持たない部分」に狭めただけなんですよね。 移行が本当に劣化していないかの検証は、これだけで記事1本になる分量なので別で書きます。 公式はSKILLとsubAgentをどう分けているのか、読み直しました ここまで書いて、公式のドキュメントと食い違ってないか不安になったので読み直しました。Claude Code のサブエージェントは、こう説明されています。 The body becomes the system prompt that guides the subagent’s behavior. （本文がサブエージェントの振る舞いを導く system prompt になる） The body should contain the persona and workflow instructions. （本文には人格と手順を書くべき） 人格は agent の本文に書け、と明記されてます。じゃあ再利用したい知識はどこに置くのかというと、そっちにも仕組みがあって、 skills フィールドでスキルの内容をサブエージェントの起動時に注入できます。公式の説明では「reusable domain knowledge を注入する」用途ですね。人格は agent、再利用する知識は skill、という分け方に見えます。 で、僕はここで一度「自分は逸脱してたのか」と思ったんですけど、公式のサンプルを見て止まりました。 --- name: code-reviewer description: Reviews code for quality and best practices tools: Read, Glob, Grep model: sonnet --- You are a code reviewer. When invoked, analyze the code and provide specific, actionable feedback on quality, security, and best practices. これ、レビュー観点が本文に書かれてるんですよね。「品質・セキュリティ・ベストプラクティスを見ろ」は人格でもあり観点でもある。つまり 内容では割れません 。観点は agent 側なのか skill 側なのか、という問いには答えが出ないんです。 割れる軸は別のところにありました。固定なのか、差し替えなのかです。 呼び出し元が1つで、その観点がずっと変わらないなら、公式のサンプルどおり本文に書いていい。困らないです。破れるのは2つ目の呼び出し元が同じ観点を欲しがった瞬間で、そこから先は人格ではなく引数になる。人格を使い回すと混ざって、混ざらないように一般化すると鈍る。公式の書き方は「1つの agent に1つの固定人格」を前提にしていて、人格が引数になる場合を想定していないんですよね。 具体で言うとこうです。レビューの器を1本作るとして、「あなたはレビューアーです」までは焼き込んでいい。呼ばれ方が変わっても、そこは動かないからです。変わるのはフロントを見るのかバックエンドを見るのかで、そこを lens-frontend.md と lens-backend.md に出す。どっちのパスを渡すかは、呼ぶ側のレビュースキルが決めます。 僕は器を機能で切ったので（読み取りだけ、書き込みあり、 Bash あり）レビュー専用の器は持ってません。でもレビュー専用に1本立てて人格を焼き込むのは、この形と矛盾しません。 基準は「呼ばれ方が変わっても動かないか」だけで、使い回す範囲が広いほど焼き込めるものが減る 、という関係なんですよね。 なお公式には「サブエージェントは1つのタスクに集中させろ」というガイドもあります。字面だけ見ると器は反しているように見えますが、これは守ってます。1回の起動は器1本と観点ファイル1枚の組み合わせで、走っている実行体は1つの観点しか見ません。焦点を与えるタイミングがファイルの中か起動時かの違いだけですね。 公式には、サブエージェントに知識を渡す skills フィールドもあります。うちでは使っていません。あれは列挙したスキルを、サブエージェントが立ち上がるたびに全文注入する仕組みで、列挙するのは agent の定義なので呼び出しごとに変えられないんですよね。 つまり skills に書くのは「 呼ばれ方が変わってもこの知識は要る 」と宣言することです。さっきの基準がそのまま当たります。レビューの器にレビュー規約を1つ載せるなら妥当だし、公式の例も API 開発のエージェントに規約とエラー処理のパターンを載せる形です。でも観点46枚を載せると、1枚しか要らない起動で45枚ぶん払うことになる。だからパスを渡して、必要な1枚だけ読ませています。 知識を references 側に構造化する話は Claude Code に専門知識を仕込む記事 の続きですね。 自分のリポで何から始めるか 持ち帰りとしては、判断はこの1問で足ります。 その観点、2つ目の呼び出し元が欲しがりますか？ 欲しがらないなら agent の本文に書いたままでいいです。欲しがったら、それはもう人格じゃなくて引数なので外に出す。手を動かす順番はこうしました。 まず model と tools と権限で並べて数える これが効きました。43本を「どのモデルか・どの道具を持っているか・どの権限か」だけで並べたら、8種類しかなかったんですよね。 18本が同じ1マスに入ってます。43本それぞれに個性があると思っていたのに、実行環境としては18本が完全に同じだったわけですね。違っていたのは観点だけでした。ここで「じゃあ観点を外に出せば、器はこの数でいい」が見えます。Read だけの7本は Read / Grep / Glob と実質差がないので上に寄せて、器は7種類になりました。 モデルの割り当ては Opus で考え、Sonnet で動かす で決めたものがそのまま残っています。器はモデルを軸に分けているので、あの配分が8種類の骨になってますね。 この7種類は移行した時点の分類で、そのあと1本増えて8本になっています。深い一次ソース追跡をやりたくなって、子のワーカーを起こせる道具を足したやつですね。道具や権限が変わるものが出てきたときだけ増えるので、観点をいくら足しても本数は動きません。 2つ目の呼び出し元が欲しがる観点だけ、ファイルに出す 全部を一気に出さなくていいです。うちは最初に表現チェックの3枚だけ切り出して、検出が落ちていないか確かめてから残りを移しました。 出すときに1つだけ注意があって、掃き方も一緒に出さないと拾えなくなります。最初にやったとき、「何を見るか」だけを観点ファイルに書いて、「どういう順で走査するか」は器の共通手順に畳んだんですよ。そうしたら同じパターンが3件あるうちの1件しか拾えませんでした。上から順に読んで気づいたものを挙げる、で済ませてしまうんですね。走査の手順は観点ごとに固有なので、観点ファイル側に必須の節として持たせました。 どこからでも呼ばれるものは、特化のまま置く そして全部を器にしなくていいです。うちにも特化のまま残しているエージェントが3本あって、どれも検索用です。ブログ記事の検索、リサーチの検索、過去の教訓の検索ですね。検索はどんな作業をしていても発生するので、 どの文脈からでも呼ばれます 。つまり呼ぶ側が特定のルーターに決まっていない。器は「ルーターが観点のパスを渡す」前提の作りなので、渡す人がいない呼び方とは噛み合わないんですよ。だから観点を自分で持ったまま置いてます。 いまは11本です。器が8本と、特化が3本ですね。43本あったときと比べて、観点の数はむしろ増えました。まとめるか分けるかで悩んでいたところが、器は使い回して観点は分ける、という形で終わりました。 まず .claude/agents/ を model と tools と権限だけで並べてみてください。同じマスに何本入っているかを見るのが、いちばん早いと思います。 コラム：公式のやり方でよくないですか？ たぶんここが気になった人がいると思うので、書いておきます。 context: fork を使っていない人は、前半は飛ばして大丈夫です。 Claude Code のスキルには context: fork という書き方があって（2.1.0・2026年1月から）、スキルの本文を別のコンテキストで走らせられます。しかも agent: を付けると実行体を選べて、公式ドキュメントにはこう書いてあります。 Options include built-in agents ( Explore , Plan , general-purpose ) or any custom subagent from .claude/agents/ . （組み込みエージェント、または .claude/agents/ の任意のカスタムサブエージェントを指定できる） つまり context: fork に agent: ro-sonnet と書けば、公式の機能だけで器に載ります。ここは認めます。 ただ、それをやると観点が SKILL.md の本文になるんですよね。タスクがファイルに固定される仕組みなので、観点を1つ足すたびにスキルが1つ増えます。そしてスキルの一覧は context: fork かどうかに関係なく起動時に全部載って、character budget を食う。budget を超えると description が切り詰められて、マッチに必要なキーワードごと落ちる。これ、僕がルーター集約の記事で書いた症状そのものです。観点46枚を全部スキルにしたら、束ねる前の状態に逆走します。 あと公式ドキュメント自体がこう警告してます。 context: fork only makes sense for skills with explicit instructions. If your skill contains guidelines like “use these API conventions” without a task, the subagent receives the guidelines but no actionable prompt, and returns without meaningful output. （明示的な指示を持つスキルにしか意味がない。タスクのないガイドラインだけだと、受け取っても実行可能なプロンプトがなく、意味のある出力を返さずに終わる） うちの観点ファイルはまさにガイドライン側なので、そのまま載せても動かないんですね。 「じゃあ組み込みの general-purpose を呼べばいいのでは」も同じ形です。あれはサブエージェントが使える道具を全部持っているので、 読み取りだけに絞る、ができないんですよね 。モデルは呼び出しごとに上書きできますが、道具は agent 定義で固定なので、呼ぶ側から渡す口がない。結果、観点も道具の指定も SKILL 側に書くことになって、器に書いてあったことを書き写すだけになります。 逆に言うと、 観点が少ないなら公式の書き方で足ります 。知識を SKILL.md の本文に畳めるなら、わざわざパスを渡す二段構えにする必要はないです。個数が問題になってくるのは観点が数十枚に育ってからで、そこまで来た人だけが今日の話を使えばいいと思ってます。 ほなまた〜 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude Codeのサブエージェントが増えすぎたので、観点を外に出しました first appeared on SIOS Tech Lab .

こんにちは！ LIFULLのマーケット横断部署でエンジニアリングマネジャーをしている吉永です。 本日は、エンジニアもサービス改善の施策を提案しやすくするために、生成AIへ調査手順や参照する情報、出力形式をまとめた、再利用可能な指示書を作った取り組みについて紹介します。 ※本記事では、この指示書を「施策提案スキル」と呼びます。 生成AIを活用してチームの企画力を広げたい方や、AIに施策案を出してもらっても一般論にとどまりがちだと感じている方の参考になれば幸いです。 取り組みを始めた背景 施策提案スキルで実現したこと 2つの使い方と、その結果 私のアプローチ: データから課題と施策を探す チームのエンジニアのアプローチ: アイデアの確からしさをAIで補強する 結果の違いから見えたドメイン知識の価値 次に取り組みたいこと 最後に 取り組みを始めた背景 実際にチームへ展開すると、2つのケースで結果に違いが出ました。一つは、私が生成AIに現状分析から施策案の作成までを任せたケースです。もう一つは、長くサービス開発に携わってきたエンジニアが自分のアイデアを生成AIで補強したケースです。 この経験から、生成AIに施策を考えてもらう際に、プロンプトやデータ分析と同じくらい大切だと感じたものがあります。それが、人が持っているドメイン知識です。 ※ここでいうドメイン知識とは、サービスの仕様やユーザー理解、過去施策の経緯など、担当業務を通じて蓄積される知識や経験のことです。 私たちのチームでは、サービス改善を企画するメンバーがSEOやCRO（Conversion Rate Optimization、コンバージョン率最適化）など、複数領域の施策を並行して担当していました。 継続的に改善を進める一方で、施策の選択肢を出し続けることには難しさがあります。特に当時は、チーム目標と現状のギャップを埋めるプランを早急に立て、実行へ移す必要がありました。 そこで考えたのが、エンジニアも施策提案に参加しやすい環境を作ることです。 エンジニアは、日々の開発を通じてサービスの仕様、データ構造、技術的な制約、ユーザー体験上の違和感に触れています。ただし、気付きを企画として説明するには、現状の数値、期待効果、過去施策との差分、A/Bテストの設計などをそろえる必要があります。アイデアはあっても、提案書へ落とし込むまでのハードルが高い状態でした。 このハードルを生成AIで下げられないかと考え、過去の不動産情報を提供するアーカイブサイトの課題抽出から改善提案までを支援するスキルを作成しました。 スキルを作成した後は、企画担当者のタスクが多く、施策を十分に検討する時間を確保しにくい一方で、チーム目標とのギャップを埋める必要があるという現状をエンジニアへ共有しました。そのうえで、「こんなスキルを作ってみたので、試しに使ってみませんか。みんなで施策案を出してみましょう」と声をかけました。 完成した仕組みを渡すだけではなく、なぜ今エンジニアからも施策案を出したいのかを伝えたことで、チームの課題を自分ごととしてとらえてもらえたと思います。 施策提案スキルで実現したこと 初版のスキルでは、生成AIに「施策を考えて」と依頼するだけではなく、施策提案に必要な調査と整理を一定の手順で進められるようにしました。 当初扱っていたのは、主に次の情報です。 行動データから、ページ閲覧や導線の利用状況を確認する ソースコードを読み、現在の仕様や実現可能性を確認する 課題、仮説、対象ユーザー、期待効果、リスクを整理する A/Bテストの指標と判断基準を含む、施策仕様書のたたき台を作る 初版で特に意識したのは、推測と事実を混ぜないことです。仮説を立てたらデータで確認し、確認できないものは仮説として残すようにしました。また、施策の魅力だけではなく、対象となるユーザーの規模、実装コスト、既存機能への影響まで整理するようにしていました。 これにより、エンジニアは自分の気付きやアイデアを入力し、企画担当者が優先度や実施可否を検討できる内容まで具体化しやすくなりました。 一方、実際に使ってみると、過去の類似施策や足元のチーム目標とのつながりまで十分に確認できないケースがありました。この点は、後述する施策案の比較を通じて見えてきた課題です。 そこで現在のスキルには、次の観点を追加しています。 関連する過去施策とA/Bテスト結果を確認し、同じ失敗を繰り返さない 足元のチーム目標や中間指標と、施策が動かす指標のつながりを確認する 「なぜ行うか」「何を変えるか」「誰に届けるか」を整理し、提案の優先理由を明確にする スキルも一度作って終わりではなく、実際の提案結果から得た学びを取り込みながら更新しています。 2つの使い方と、その結果 スキルを使って、私とチームのエンジニアがそれぞれ施策案を作りました。興味深かったのは、同じスキルを使っていても、生成AIへの入り口が異なっていたことです。 私のアプローチ チームのエンジニアのアプローチ 出発点 まず行動データを分析する 日々感じていた改善アイデアを入力する 生成AIの役割 数値から課題を抽出し、施策案を広く作る アイデアの確からしさをデータや過去事例で検証する 人が主に提供したもの 分析対象と目標 仮説、ユーザー理解、実装経験、過去施策の記憶 結果 複数の案を作ったが、実施候補には選ばれなかった 2件が実施候補に選ばれ、いずれもA/Bテストでエンジニアが提案したBパターンが既存パターンを上回り、採用された 私のアプローチ: データから課題と施策を探す 私は、行動分析ツールのデータから現状を把握し、課題を抽出したうえで改善案を作るところまで生成AIに依頼しました。 生成AIは、複数のデータや実装を横断し、短時間で施策候補を並べることには向いていました。施策ごとの期待効果や実装コストも整理できたため、検討材料を増やすという点では役立ちました。 一方で、作成した案は実施には至りませんでした。 実施に至らなかったのは、案そのものが成立していなかったためではありません。中には、過去に類似施策を実施し、A/Bテストで新しいパターンが既存パターンを下回っていた案もありました。また、足元で改善したい指標へ直接つながらず、優先度が下がった案もありました。 データから一見妥当に見える改善余地を見つけるだけでは、今その施策を選ぶ理由として十分ではありません。過去の失敗を踏まえて再挑戦するなら何を変えるのか、現在の目標に対してどの指標を動かすのかまでつながって、初めて実行候補になります。初版のスキルには、その判断に必要な文脈を確認する仕組みが不足していました。この経験が、過去施策の結果と足元の目標指標を確認する現在の形へ更新するきっかけになりました。 チームのエンジニアのアプローチ: アイデアの確からしさをAIで補強する 今回施策を提案したのは、長年アーカイブサイトのフロントエンド開発に携わっているチームメンバーです。 開発を通じて、過去にどのような施策を実施し、何がうまくいかなかったかを知っています。さらに、普段の開発やサービス利用の中で感じていた改善アイデアも持っていました。 今回は、そうした経験から生まれたアイデアを生成AIに入力し、関連する行動データや過去施策を調べてもらうことで、仮説の確からしさを補強しました。つまり、AIにゼロから施策を発明してもらうのではなく、自分の中にある仮説を検証し、企画として説明できる形へ整えるために使ったのです。 その中から2件が実施候補に選ばれました。どちらのA/Bテストでも、エンジニア提案のBパターンが既存パターンを上回り、採用されました。エンジニアのアイデアが提案で終わらず、検証と本実装まで進んだことは大きな成果でした。 結果の違いから見えたドメイン知識の価値 この結果だけで、データ起点のアプローチが悪く、アイデア起点のアプローチが常に正しいとは言えません。試した施策の性質や優先順位も異なるため、単純な比較はできないと思います。 それでも、今回の経験から強く感じたのは、生成AIは入力された情報を増幅する存在だということです。 チームのエンジニアが入力したのは、施策のアイデアだけではありません。その背景には、長年の開発で蓄積した次のような情報がありました。 ユーザーが画面上で迷いやすい箇所 過去に試した施策と、その成否だけでは表せない学び データやコードがその形になっている理由 実装コストや既存機能への影響に関する感覚 日々の開発で感じていた、小さな違和感や改善の余地 これらは、データベースやドキュメントを検索するだけでは、すべてを取得できるとは限りません。人の中にある経験知と、生成AIが集められるデータや実装情報が組み合わさったことで、提案の説得力が増したのだと思います。 生成AIによって、調査や資料化のコストは大きく下げられます。一方で、調べる対象や深掘りする違和感を選び、結果を業務の文脈で解釈するには、引き続きドメイン知識が必要です。 生成AIの急速な高度化に伴い、人間の業務を支援・代替する場面も増えています。私自身、これから人の役割はどう変わっていくのだろうと考えていました。 しかし、今回の2施策では、エンジニア提案のBパターンが既存パターンを上回りました。その結果を見て、ドメイン知識を持つ人の役割はまだまだ大きいと感じました。AIが十分なデータへアクセスできても、最初に渡す問いや仮説の質、その結果を業務の文脈で解釈する力によって、得られる成果は変わります。 人間にしか担えない領域はまだあります。生成AIが発達しても、担当するサービスや業務への理解を深める重要性は変わらないと思います。むしろ、生成AIが知識やアイデアを増幅できるようになったことで、入力となるドメイン知識の価値がさらに高まるのではないかと感じています。 次に取り組みたいこと 今回のスキルには、行動データ、ソースコード、計測仕様、過去の施策資料など、すでに言語化されている情報を参照できるようにしました。 次の課題は、人だけが持っている情報を、生成AIが利用しやすい形に整えることです。 たとえば、次のような情報を継続的に残せると、施策提案の質をさらに高められると考えています。 施策を実施した事実だけでなく、当時の仮説と判断理由 A/Bテストで勝った理由、負けた理由についての振り返り 見送った案と、見送った時点の制約 開発や問い合わせ対応で感じたユーザー体験上の違和感 サービス固有の用語、データの定義、実装上の制約 ただし、すべてを無制限にAIへ渡せばよいわけではありません。情報の公開範囲、個人情報や機密情報の取り扱い、古くなった知識の更新方法、AIが参照した根拠を追える状態も合わせて設計する必要があります。 最終的には、職種に関係なく、誰でも気軽に質の高い施策提案ができる状態を目指しています。人のアイデアと経験を起点に、生成AIが調査、検証、具体化を支援する。その積み重ねによって、企画担当者の負荷を分散するだけでなく、チーム全体でサービスを良くする文化につなげていきたいと思います。 最後に 今回の取り組みを通じて、生成AIが得意なことと、人が持つ知識の価値をあらためて考えることができました。 生成AIに施策案を作ってもらう際は、いきなり「改善案を出して」と依頼するのではなく、まずチームが持っている仮説や過去の経験を入力できないか考えてみると、結果が変わるかもしれません。 チームで生成AIを使った施策提案に取り組む方の参考になれば幸いです。最後まで読んでいただきありがとうございました！ 最後に、LIFULLではともに挑戦していける仲間を募集しています。ご興味をお持ちいただけましたら、ぜひ以下のページもご覧ください。 hrmos.co hrmos.co

「技術ブログを書け、PVを伸ばせ」と言われたあなたへ ども！1年間AIと一緒に活動してきた龍ちゃんです。 「技術ブログを書け、PVを伸ばせ」 会社からそう言われているエンジニア、いませんか？文章書くのは苦痛で、タイトルの付け方もメタディスクリプションの書き方もマーケの話も全然わからない。 先に、この記事で渡したいものだけ。個別のTipsでも「AIがすごい」って話でもなくて、 文章が苦手なエンジニアでも、ネタ切れせずにブログを続けられる仕組み です。検証から公開までの全工程を、ひとつのパイプラインとして見せます。タイトルもマーケも苦手なまま始められますよ。 これだけ「苦手」と言っておきながら、「この1年でAI活用が一番進んだ業務は？」と聞かれたら、答えはブログなんですよね。書き方も、昔は「やったことを順に書く実装ログ」だったのが、今は「読者のつまずきを起点に、検証結果を証拠として置く」形に変わりました。同じ人間が書いてるのに、です。AI活用の集大成として、今回まとめることにしました。 ちょうど1年前にも 「これが僕の執筆環境です」という記事 を1本書いてるんですけど、そこから工程ごとに道具を足し続けた結果が、今回話すパイプラインです。 大事にしている考え方は2つあります。 検証してから書く 。ネタを探してから書くのではなく、検証した結果が記事になる。だからネタに詰まらない 道具を使い捨てず仕組みに沈める 。便利な使い方をその場限りにせず、次も使えるように残す 順番に説明していきますね。 検証・調査からはじまる、Claude Codeで組んだパイプラインの全体像 まずざっくり全体を見てもらいます。 全工程にAIが居ます。調査もアウトライン作りも公開前のチェックも図もサムネも、どこを切ってもAIが何かやってます。ただ、 執筆だけ役割が反転します 。他の工程はAI主導で人間が確認するイメージなんですが、執筆だけは人間主導でAIが補助に回る。なぜそうなるのか、は後半で回収しますね。 なお、この記事に出てくる research-searcher みたいな名前は、それぞれ役割を持たせたAIに付けた呼び名です（僕は Claude Code の skill とサブエージェントで組んでます）。名前は覚えなくて大丈夫なので、「何をする担当か」だけ追ってもらえればOKです。あと、これ全部を自作しないと始まらない話でもないです。普段使ってるAIに同じ役割を振るだけでも回ります。 もう1つ前置きを。7工程のうち5つ（アウトライン / 執筆 / 公開前チェック / 図・サムネ / タイトル・SEO）は、それぞれ単独の記事で深掘りしてあります。なのでこの記事では、その5工程は「何をする工程で、なぜその形にしたか」と、さらっとしたコツだけを置いておきます。気になる方はぜひ個別記事も読んでみてください。 工程ごとに、上流から歩いてみる 工程は7つ。順に見ていくと、AIへの任せ方が工程ごとに違うのが見えてくると思います。 検証してから書く。だからネタ切れしない ブログの起点は「ネタ出し」じゃないんですよね。「検証・調査」なんです。 「よくネタが尽きないね？」って聞かれることがあるんですが、答えはシンプルで、自分の中に1つルールがあって。 検証した内容を基本的にブログ化する ってことを守ってます。 何か気になる技術があって、実際に手を動かして、「あ、こういう結果になった。これはブログにする価値があるな」と判断してから書く。逆に、ネタだけ考えて実装なしで「仮想のブログ」を書こうと思えば書けるんですけど、個人的にそれをやったら終わりだなと思ってて。技術ブログとして 動くものを提供できる 状態を維持することは、最低限守ることにしてます。 ここで効いてくるのが、 検証する場所と記事を書く場所が同じリポジトリにある 、という構成です。気になったら即AIに調べさせて 「放置案件」を作らない 。 調査の品質を /research で揃えて から書き始めると、書いてる途中で主張がブレなくなる。そうやって手を動かした結果は、 docs/research や docs/experiment にメモとして溜まっていきます。検証と執筆が地続きだから、検証した結果がそのまま記事の素材になるんですよね。 で、ネタの話なんですけど。溜まった検証メモを横断検索すると、「これ1記事になるな」という種が自然と立つんですよ。ここは Skill×サブエージェントで調査を速く回す構成 にした専用のエージェント（調査メモを横断検索する research-searcher や、過去のブログを照合する blog-searcher ）に探させてます。だから僕の中に「ネタを探すフェーズ」って実はないんですよ。むしろ逆で、 検証したことがネタになる んだから、検証していないことはそもそも記事にならない。ネタは探すものじゃなくて、検証から生まれるものなんです。そう捉えると、手を動かして検証を続けている限り、「ネタ切れ」という状態そのものが起きなくなるんですよね。「ネタを探す」は「自分の活動の振り返り」に近いかもしれません。 いきなり書かず、アウトラインで勝負を決める ネタが決まったら、次はアウトラインです。誰に・どの検索で届く記事か・どの角度で書くかを、本文を書く前に決めきる工程ですね。少しマーケティング的知識を入れておきます。 書く前に決めきる理由は単純で、「誰に届ける記事か」の設計は執筆より上流でしか機能しないからです。書き始めてから「あ、読者像ずれてたな」となると直すのが本当に大変なので。あと、ここで「うーん、わざわざ書くほどでもないな」となった記事を、1文字も書かずに畳めるのも大きいです。 この工程のコツを1つ。 アウトラインが「方法をN個並べる」形になったら、1記事に詰めるのをやめて分けたほうがいい です。見るのは、並べた方法どうしで読者に要求する思考が同じかどうか。「読者のペインが同じ」はまとめる理由になりません。実はこのシリーズがまさにそれで、最初は1本に詰めるつもりだったのが、工程ごとに読者へ要求する思考が違いすぎて5本に割れました。あと量の目安として、アウトラインは50〜60行で止めてます。超えたら本文を先食いしてるサインで、執筆が「アウトラインの清書」になるんですよね。 アウトラインを先に作ることで、前提知識などが見えてくることがあります。そういった「自分は知っている」けど、みたいな情報に気づくとまたそれも新規のブログネタになるという感じですね。あとは分量が増えたら分割みたいなこともとれるので、時間がなくてもサクッとアウトラインだけ作るのはおすすめです。AIと話して作ればそんなに時間もかからないですしねw そのアウトラインをAIにレビューさせる話（狙う角度を探す担当と、読者の代弁をする担当の2体）は、別記事に書きました。 2026-08-06 技術ブログの手戻りが消える、アウトラインのAIレビュー 執筆は、素材を渡して下書きを作り、最後は自分の目で通す 執筆は、ここまでで溜めた検証メモ・調査・過去記事を素材として渡して、文体を担当するAI（writing-stylist）に下書きを起こさせる工程です。音声入力でしゃべった内容を素材に混ぜることもあります。 ただ1個だけ、あえて仕組みに「落とさない」ところがあって。出てきた下書きを 自分の目で見て「これ、自分が書きそうか？」を判断して直す 。ここはAIに渡さず自分でやります。 正直、執筆の完全分離はできずにAIとけんかしている日々ですね。それでも執筆速度自体は上がっているので結構お勧めな手法です。 自分の文体をどこまで再現できて、どこから中身が捏造されるのか。その実物は別記事にあります。 2026-08-06 技術ブログで自分の文体をAIに再現させて時短を目指す 公開前は1体に全部見せず、観点で割る 下書きができたら、公開前に検査します。 ここで大事なのは、1体のAIにレビュー観点を盛り込みすぎないことです。それをやると観点が混ざって、「全体的によく整理されています」みたいな当たり障りない感想しか返ってこない。なので 観点ごとに別のAIに割って 、1体には1つだけ目的を持たせてます。いま割ってるのは、書いてはいけないことが混ざってないかのリスク検査、辛口の批評、論理の検算です。割ると、各担当が遠慮なく尖った指摘を返してくるんですよね。 ここで効いてるやり方が2つあって。 1つは、 表現の検査を別立てにする ことです。過剰な言い切り、前振りのない唐突な話題転換、「様々な」みたいなぼかし語といったやつですね。これは論理の破綻とは別の壊れ方なので、専用の担当に分けたほうが当たります。あわせて、約物（記号やカッコの揺れ）はAIに判断させず、スクリプトで機械的に正規化してます。揺れてるかどうかは読まなくても分かるので、ここにAIを使うのはもったいないんですよね。 もう1つは、 内部リンクをAIに探させる ことです。公開済みの記事を全部リポジトリに取り込んであるので、「この段落から張れる過去記事ある？」と聞けるんです。自分の記憶で思い出せる過去記事なんて直近の数本だけなので、ここはAIに探させた方が確実です。これは後で出てくる「1リポジトリに集約する」構成の副産物ですね。 検査の中身と、どこまで無人化してどこから人間が裁くのかは、別記事で書きました。 2026-08-06 技術ブログの公開前チェックをAIに任せる：機械が弾き、人が裁く 図とサムネはAIに作らせて、いい出来は貯めて育てる 記事が一通りできたら、図とサムネを付けます。 ここもAIに作らせてます。図は説明したい構造をそのまま渡してHTML＋Tailwindで組んでもらい、それをPNGに変換します。サムネは記事のタイトルと内容を渡して生成する感じですね。文章だけで説明していたところに図が1枚入ると、理解のしやすさが結構変わるんですよね。 最初から一発でいい感じに出てくるわけではないので、出来を見て「もうちょっと詰めて」と作り直すループを回します。そして、いい図ができたらそれを references に保存しておく。次に作図させるとき、それが“お手本”として効いてくるんですよね。この記事に載っている図も、全部この流れで作りました。 サムネイルに関しては、HTMLのコードをパターンとして保存しておくことで再利用ができるようになっています。HTML→PNGの撮影もPlaywrightを使用するとAIが勝手に判断してくれて撮影まで行ってくれるので超便利ですね。 なお、図を「作る」ことより残ってた判断は「どこに置くか」なんですが、そっちの話は1本に切り出しました。 2026-08-06 ブログの図は「どこに入れるか」をAIに決めさせる 作り方を具体的に知りたい人はこちら。 Mermaid図をAIで自動生成する — フロー図やシーケンス図を、Figmaで2時間かけてたのが5分に。最初に試すならここから 図解をAIに丸投げして育てる — 気に入った図をreferenceに貯めるだけで、AIの作図が勝手に上手くなっていく仕組みの話 タイトルとSEOは、マーケティングを知らないままAIで補える 正直、文章を作るよりも苦手だった領域です。タイトルの付け方、メタディスクリプション、競合調査。マーケッターの方に聞いても何から手を付けていいか全然分からなくて、最初にAIに任せ始めたのもここからでした。 やってることは2段階で、上位記事のタイトルの付け方を調べさせて相場を掴んでから、自分の記事のタイトルとメタの案を出させる。採るか直すかは自分で決めます。ここがAIに任せやすいのは、 正しさの基準が自分の外にあるから なんですよね。上位に並んでる記事の付け方が相場で、公開後のPVが答え合わせになる。SEOの知識が自分になくても、相場に照らせば案の良し悪しは判断できるわけです。 1つだけ書いておくと、 タイトルを詰めるついでに、各章の見出しも一緒に見直します 。見出しは執筆しながら立てるんですが、書き終わってから読むと、看板に内輪の用語（エラーの内部名とか実装用語）が乗ってることがあるんですよ。それが出たら文言をいじって済ませず、その章が書き手目線になってるサインとして中身の順番から疑います。看板は「困ってる人が打つ言葉」で書きたいので。 正直に言うと、この工程はまだ仕組み化の途上です。「仕組み完成してます！」と書きたいところですが、そうじゃないので正直に書いておきます。 2026-08-06 技術ブログのタイトルとSEOは、書いた後にAIで詰める 公開したら記録する。書いて終わりにしない 公開して終わり、にはしてないんですよ。 ここで効いてくるのが、また「1リポジトリに集約してある」という構成です。公開した記事も、そのPVデータも、同じリポジトリに置いてある。すると PV分析をこのリポジトリの中で回せる んですよね。このブログはどういう読者層に届いて、なぜ伸びたのか。それを分析して、次の記事のアウトライン（企画）に戻す。 ポイントは「作業ログを残す」というより、 後から参照できる資産として記事と分析結果が同じ場所にある ことです。記事の中身も、PV分析の結果も、ひとつながりで手元に残る。 実際これが効いたことがあって。リポジトリの中でPVを分析したら、生成AI系の記事が圧倒的に読まれていて（うちのブログの場合、PVの8割以上がそこ）、その中でも伸びてるのはツール名を題に置いた実用ノウハウ系で、しかも新記事を出さない月は数字が落ちる、というのが見えたんですよ。結論はシンプルで「 Claude Code 系に絞って、新規記事をとにかく出し続けろ 」。で、実際にそのテーマでシリーズを書き始めました。分析と記事と過去ログが同じリポジトリにあるから、「数字 → 次に何を書くか」の判断をそのまま回せるんですよね。 調査メモも記事の素材も過去ログもPVデータも同じ場所にあると、「次に何を書くか」を決めるのに別の場所を探しに行かなくて済むんですよね。正直やってみないと分からないんですが、続けてみると「あ、これか」ってなると思います。 記録と集約は、それぞれ単独記事にしてます。 git logを作業ログにする話 — コミットをAIに書かせるだけで、git logがそのまま作業履歴に。中断からの復帰や週次の振り返りがラクになる 全業務を1リポジトリに集約した話 — 開発も調査もブログも1つのリポジトリへ。やった仕事が消えず「資産」として積み上がる作業基盤の作り方 全工程に共通して効いてる考え方 工程を全部並べてみると、根っこに通ってるものが見えてきます。冒頭で2つ挙げましたが、こうして並べるともう1つ足したくなるので、3つにして書いておきます。 ① 検証が先、ネタは後 ネタを探すのではなく、検証する。検証したことがネタになるんだから、検証していないことは記事にもならない。記事は検証の副産物として立ち上がるもので、この順番にしておくと「ネタ切れ」という発想自体がなくなるんですよね。 ② 便利技は使い捨てず仕組みに沈める 「これ便利だな」で終わらせない。一番手軽なのは、良い結果が出たら reference に保存して次のAIへの参考資料にすること（さっきの図・サムネが育つのがこれ）。もう一歩進めると、繰り返す作業はスキルやエージェントの形にして残す。どちらも「その場限りにしない」という同じ原則で、保存はその入口です。次に使うとき1から作り直さなくていいので、この積み上げがじわじわ効いてきます。 ③ 1体に欲張らず、観点で割る 公開前チェックのところで出てきましたが、1体のAIに全部やらせると観点が混ざります。用途ごとに割った方が、各エージェントが遠慮なく動くんですよね。これはレビューに限らず、他の工程でも同じ考え方です。 AI全部入りでも、最後に残るのは「これ自分が書きそう？」の判断 自分らしさとAIっぽさのせめぎ合い。その摩擦の中で、自分の言葉が研がれていく。 ここまで見てきた通り、検証から公開まで全工程にAIが居ます。執筆にもAIは居ます。文体エージェント（writing-stylist）が下書きを作るし、音声入力で口述することもある。 でも、執筆だけ役割が逆なんですよね。 他の工程はAIが主導して人間が確認する形ですが、執筆は人間が主導してAIが補助に回る。なんでそうなるか。 理由は、AIの出力が「合ってるか」を測る基準が、工程ごとに違うからなんですよね。もちろん他の工程も、最後は人間が見ます。でも図やSEOや調査は、合ってるか外してるかの基準が外側にある。図がちゃんと描けてるか、検索意図に合うタイトルか、事実が正しいか。だから人間は「確認役」で済む。ところが文章の「自分らしさ」だけは、基準が自分の中にしかなくて、誰かに「合ってます」と言ってもらえない。だから執筆だけ、確認じゃなく「主導」に回るんです。 AIが出してきた文章を読むじゃないですか。読んでいると、「これはちょっと違う」「ここは自分ならこう言わないな」って思う部分が出てくるんですよ。そこを直す。その修正の過程で自分らしさが入ってくるんですよね。音声入力でしゃべった言葉も同じで、そのまま入れるんじゃなくて「これは自分が言いそうか？」を確かめながら使う形ですね。 残るのは「文章をうまく書く力」じゃないんですよね。「 これ、自分が書きそうか？ 」を判断する力なんです。 まぁ正直、この作業をなくしてしまえば今の3倍ぐらいの量のブログを出せますね。ただ、それはただの量産作業な気がしてしまいます。なんとなく愛着も湧かないですよね。文体と自己が乖離しちゃうというか。割と大事にしている考え方です。 これ、「技術ブログを書け」と言われてるエンジニアへのアンサーでもあって。2つ理由があります。 ひとつは、だから量産する意味がないということです。自分らしさをメッセージとして注入していく作業なので、機械的に数を増やすのとは違うんですよね。感覚としては「自分らしさとAIっぽさのバトル」みたいな感じですw ちゃんとそれなりに疲弊します。 もうひとつは、実装した内容は、実装した自分にしか正しく判断できないということです。検証して動かした結果について「これは本当にこうだったか？」を確かめられるのは、手を動かした本人だけです。だから最終チェックは絶対に人間が要る。 ここが面白いなと思ってて。「いきなり自分らしく書け」って言われても、何が自分らしいのかって分からないじゃないですか。でも「AIが出してきた文章を見て、違うと感じる所を直す」なら、誰でもできるんですよ。生成より添削の方が、自分を出しやすい。文章を書くのが苦痛な自分でもこのパイプラインが回ってる理由は、ここだと思ってます。 何から始めるか、そして正直な限界 まず何から始めるか 「で、何から始めればいい？」と思った方へ。 おすすめは、 苦手な1工程からAIに任せてみる ことです。順番はこんな感じ。 苦手な工程を1つ選ぶ （僕はタイトルとメタディスクリプションでした）。使うAIは普段のもので大丈夫です。ChatGPT でも Gemini でも、Claude Code でも 過去記事があれば、何本かAIに読ませて文体や思想を抽出してもらう （まだ1本も無ければ、ここは飛ばしてOK） AIが出した案を「これ自分が書きそう？」で直す 。気に入らない所を直すだけでOK（生成より添削の方がラク） これだけで1工程は回り始めます。いきなりパイプライン全部を組もうとしなくて大丈夫。苦手なところを1個ずつ潰していくと、じわじわ繋がってきます。 もっと手っ取り早く全体像を相談したいなら、この記事ごと自分のAIに読ませて「マネできそうな所ある？」と聞くのもアリです。状況に合いそうな工程を拾ってくれます。 正直な限界 誇張したくないので書いておきます。 まず、 ネタや「気になる！」は人間発信 です。そこにモチベがないと、そもそも書かない。仕組みは「書こうとした人の作業を楽にする」ものなので、動機まで代替はできないですw あと、 最初から完成形は組めない です。続けてみて初めて「ここ変えよう・ああしよう」が出てくる。この記事で紹介した形も、1年かけて少しずつ固まってきたものです。最初から全部揃えようとしなくていいです。 文章を書く苦痛がゼロになるわけでもないです。相変わらず書くのしんどいですよw マーケ周りの分析もまだ仕組み化の途上で、手動でやってる部分があります。 まとめ：個人で完結する領域だからこそ、AIを試せた この1年で一番腑に落ちたことがあって。同じAI活用でも、本職のコードを書く仕事とブログでは勝手が全然違うということです。 本職のエンジニアの仕事でエージェントを使うとなると、結構ハードルがあるんですよ。後のメンテナンスとか、決定事項を流動的に把握しておかないといけなくて、AIに自由にやらせるというより、ガチガチに縛って使うことになる。 でもブログは違うんですよね。僕個人で完結するコンテンツなので、僕がどう思うかだけで決まる。だから 自分が使いやすいように、好きなだけ環境を整えられる 。 そして、この「自分が使いやすい環境を整える」行為そのものが、AI活用を学ぶ一番の場になったんです。skill の作り方、agent の設計、観点の分け方、みんなここで学びました。本職のコードを書く現場では踏み込みづらかった領域に、ブログという個人完結の場だからこそ踏み込めた。それが一番の収穫だったと思ってます。 パイプラインは人によって違っていいんですよ。「自分はこの工程が苦手」「ここは手放したくない」は人それぞれです。残すべき人間の領分を自分なりに見極めていく、その過程がたぶん大事で。 文章を書くのは相変わらず好きじゃないんですけど、「AI活用が一番できてる業務は何か」と聞かれたらブログだって答えると思います。それがこの1年の一番の発見でした。 ほなまた〜 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude Codeと書く技術ブログ：ネタ切れしない仕組みの作り方 first appeared on SIOS Tech Lab .