にわかPC自作erのAI勉強ノート: Claude

ラベル Claude の投稿を表示しています。すべての投稿を表示

2026年4月8日水曜日

Claude Pro 20ドル運用レビュー｜火力は高いが、毎日使うAIではなかった

※この記事は2026年4月時点の使用感です。

AI系の機能や使い勝手は更新が速いため、その時点の実運用メモとして読んでください。

ここ最近、ChatGPT Plus と Codex の使用感を書いた。

自分の中では、ChatGPT Plus は 入口AI だった。
思いつきを投げる。壁打ちする。スマホから戻ってくる。
そういう、毎日雑に使いやすい場所としてかなり強い。

一方で Codex は、手を動かす係 に近い。
ファイルを見て、Vault を整理して、関連記事や handoff メモを更新して、daily に残す。
実際に作業を進める相手としてかなり助かっている。

では Claude はどこに置いているのか。

今の自分の感覚では、Claude は火力が高い。
ただし、20ドル前後の課金運用で見ると、雑に長く回すAIというより、使いどころを選ぶAI だと感じている。

深めの整理や構造化ではかなり強い

Claude を使っていてまず感じるのは、長めの文章や複雑な相談を整理する力の強さだ。

まとまっていないメモを読ませて、論点を分けてもらう。
会話の流れを要約してもらう。
Obsidian のメモを前提に、次に何をするか相談する。

こういう場面ではかなり頼りになる。

特に自分の場合、Obsidian にメモを溜めながら AI と一緒に運用を考えているので、長文の文脈を読んで構造化してくれる力はかなりありがたい。

ChatGPT Plus が入口だとすると、Claude はもう少し奥にいる。
思いつきを雑に投げる場所というより、ある程度まとまった素材を渡して、深く整理してもらう場所 という感じがある。

Cowork や Obsidian 運用との相性はかなり良い

Claude 系の強さを一番感じたのは、Cowork や Obsidian と組み合わせて使った時だった。

Vault のメモを前提に、どのメモをどう扱うか相談する。
inbox の整理方針を考える。
ブログ下書きの流れを見てもらう。
スキルの設計を言語化する。

こういう 文脈込みの相談 ではかなり強い。

単発の質問というより、今までの流れを踏まえて、次に何をするかを考える相手として使いやすかった。

だから、Claude は自分にとってかなり重要なAIではある。
少なくとも、Obsidian 運用や長文整理の場面では、今でも頼りたいと思うことが多い。

ただ、制限はかなり気になりやすい

一方で、20ドル前後の課金運用として見ると、制限はかなり気になる。

Claude は火力が高い。
でも、その火力を雑に長く使い続けると、制限が頭をよぎる。

重いモデルを使ったり、長文を何度も読ませたり、Claude Code や Cowork でがっつり作業を進めたりすると、
「このまま続けて大丈夫かな」
と思う場面がある。

これは、回答の質とは別の話だ。

どれだけ賢くても、途中で止まるかもしれないと思うと、頼む作業の粒度が慎重になる。
ちょっとした壁打ちや軽い確認まで全部 Claude に投げるというより、
「ここは Claude に投げる価値があるか」
を考えるようになる。

雑に回す枠ではなく、本命処理に置く方がしっくりきた

使っていてしっくりきたのは、Claude を 本命処理 に置く考え方だった。

たとえば、

長いメモを構造化したい
Obsidian の流れを前提に相談したい
ブログや方針メモを深めに整理したい
複雑な話を、読みやすい形にほどいてほしい

こういう場面では、Claude に頼みたくなる。

逆に、

とりあえず思いつきを投げる
軽い壁打ちをする
スマホから雑に話しかける
ファイル整理を淡々と進める

このあたりは、別のAIに逃がした方が気が楽だった。

入口は ChatGPT Plus。
ファイル作業は Codex。
深い整理や文脈込みの相談は Claude。

今のところ、このくらいの分け方が自分には合っている。

Claude に寄せすぎないために、Vault 側も整えるようになった

Claude と Obsidian の相性はかなり良い。
ただ、その相性が良いからこそ、Vault 運用を Claude だけに寄せすぎるのは少し怖いとも感じるようになった。

AI は更新が速い。
使い勝手も変わる。
制限もある。
もし特定のAIに運用が寄りすぎると、そのAIが使いにくい時に自分の作業まで止まってしまう。

だから最近は、Vault 側を
「どのAIでも最低限読める形」
に寄せている。

Markdown で残す
frontmatter は最小限にする
inbox は役割を混ぜすぎない
handoff メモを残す
daily に進捗を残す

こうしておけば、Claude だけでなく、Codex や他のAIにも渡しやすい。

Claude が強いからこそ、全部を Claude に抱え込ませるのではなく、他のAIにも逃がせる形を作っておく。
最近はその方が安心感がある。

Codex と比べると、タフさの差も見えてくる

Codex を使うようになって、Claude の位置づけはさらに見えやすくなった。

Codex は、ファイル作業や Vault 整理をかなり長く進めても、体感では制限をあまり気にせず使えている。
もちろん用途が違うので単純比較はできない。

でも、自分の使い方では、
「長く淡々と作業を進める」
という点では Codex の方が気楽だった。

一方で Claude は、1回の整理力や文脈込みの相談でかなり強い。

だから、どちらが上というより、置き場所が違う。
Claude は火力枠。
Codex は実務枠。

この感覚ができてから、無理に Claude へ全部投げようとしなくなった。

20ドル課金で見ると、Claude は「勝負球」に近い

20ドル前後の課金運用で見ると、Claude は自分にとって 勝負球 に近い。

毎日雑に何でも投げるというより、

ここは深く整理したい
ここは文脈を読んでほしい
ここは少し重いけど Claude に頼みたい

という時に使う。

この使い方なら、かなり満足度は高い。

ただし、ChatGPT Plus のような入口AIとして使うには少し重い。
Codex のように長く作業を進める実務担当として使うにも、制限が気になる場面がある。

だから自分の中では、Claude は
「強いけれど、使いどころを選ぶAI」
という位置づけになっている。

まとめ

Claude は、火力が高い。
長文整理、構造化、Obsidian や Cowork を前提にした相談ではかなり頼りになる。

ただ、20ドル前後の課金運用として見ると、雑に長く回すAIではなかった。
制限が気になりやすいので、何でもかんでも投げるより、本命処理に置く方がしっくりきた。

ChatGPT Plus が入口AIなら、Codex は手を動かすAI。
そして Claude は、深く整理したい時の火力AI。

今のところ、自分の中ではそんな位置づけになっている。

もちろん、これは 2026年4月時点 の使用感だ。
今後の更新や制限の変化で印象は変わるかもしれない。

でも少なくとも今は、Claude はかなり強い。
ただし、20ドル運用では使いどころを選ぶ。
そう感じている。

2026年4月5日日曜日

Coworkのスキルを増やしていったら、「設計の型」が見えてきた

Cowork には「スキル」という仕組みがある。

自分がよくやる作業手順をファイルとして書いておくと、AI がそれを読んで、同じ流れで動きやすくなる機能だ。

以前の記事で、最初の1本である blog-manager を作った時の体験を書いた。
あのときは、手順を言語化するのが一番難しい という話だった。

今回は、その後に inbox-triage、daily-update、save-summary とスキルを増やしていく中で見えてきたことを書いてみる。

結論を先に言うと、どのスキルも結局は同じ流れで動いている ことに気づいた。
そして、最初のスキルで一番迷ったのは、ワークフローをどう分けるか だった。

最初のスキルは、全部入りにしようとして詰まった

blog-manager を作ったとき、最初に書こうとしたのは「ブログ記事を書く手順」全体だった。

ネタ出し、選定、下書き作成、保存。
全部をひとつの流れとして書こうとした。

ところが、実際の運用を考えると、毎回ネタ出しから下書きまで一気にやるわけではない。

今日はネタだけ出しておきたい
前に出したネタの中から1本選んで書きたい
書かないけど、アイデアだけストックしたい

使い方は思っていたよりバラバラだった。

ひとつの手順書に全部を書くと、AI はかなり律儀に最初から最後まで走ろうとする。
「ネタだけ出して」と言っても、下書きまで進もうとしたり、保存先の確認を始めたりする。

やりたいことと、動き方が少しずつズレる。

そこで、ワークフローを

A: ネタ出し
B: 下書き作成
C: アイデア保存

のように分けることにした。
それぞれに 「いつ起動するか」 のトリガーを書いて、独立して動けるようにした。

この 「分ける」判断 が、最初のスキルで一番時間がかかった部分だった。

2本目以降で気づいた「共通の流れ」

blog-manager の後に作ったのは、

inbox-triage
daily-update
save-summary

の3つだった。

作っているうちに、どれも結局同じ流れで動いていることに気づいた。

何かを読む
inbox ファイル、会話ログ、blog_ideas.md など
整理・加工する
トリアージ、要約、ネタ出しなど
確認を挟む
ユーザーに見せて「これでいいか」を聞く
保存する
指定のファイルに書き込む

たとえば inbox-triage なら、

inbox を読む
整理案を出す
確認する
各ファイルに振り分ける

という流れになる。

daily-update なら、

今日のログを受け取る
daily 形式にまとめる
確認する
daily ノートに保存する

save-summary も同じだった。

違うのは 何を読むか と どう加工するか だけで、骨組みは同じだった。

2本目の inbox-triage を作るとき、最初は白紙から書き始めようとした。
でも途中で、
「これ、blog-manager の一部と構造が同じだな」
と気づいて、そこから流用した。

3本目以降はさらに早くなった。

ワークフローを分けるかどうかの基準も見えてきた

blog-manager はワークフローを複数に分けた。
一方で、inbox-triage や daily-update は分けていない。

この違いはどこから来るのか。
振り返ってみると、基準はかなりシンプルだった。

途中で止めたいことがあるかどうか だ。

blog-manager の場合は、

ネタ出しだけで終わりたい日がある
下書きだけ書きたい日もある
アイデア保存だけしたい時もある

つまり、途中で止める使い方が普通にある。
だから分けた。

一方で inbox-triage の場合は、

inbox を読む
整理案を出す

ここまでは毎回やる。
確認を挟むタイミングはあるけれど、それはワークフロー内の ステップ であって、別ワークフローにするほどではない。

だから分けなかった。

つまり、
「違うタイミングで呼びたい単位」がワークフローの区切りになる
ということだった。

これは作る前には分からなくて、実際に使ってみて
「毎回ネタ出しから始まるのが面倒」
と感じた時に初めて見えてきた。

「確認を挟む」は、どのスキルにも共通で必要だった

もうひとつ、スキルを増やす中で固まってきたルールがある。
それは、AI が勝手に書き込まない ということだった。

inbox-triage では
「勝手に書き込まない・必ず確認を挟む」
を原則として最初に書いた。

これは blog-manager を使っているときに、確認なしにファイルが更新されて
「あれ、変わってる」
となった経験から来ている。

情報の整理や保存は、間違っていても気づきにくい。
だから、

整理案を出す
見せる
OK が出たら書く

という流れを、どのスキルにも入れるようにした。

daily-update でも、保存前に
「この内容で保存してよいですか？」
と確認を挟むようにしている。
save-summary も同じだ。

結果として、

読む → 加工する → 確認する → 保存する

この4ステップが、全スキル共通のテンプレートになった。

設計の「型」ができると、迷いがかなり減る

スキルを3つ、4つと増やしていく中で、一番変わったのは
新しいスキルを作るときの迷いが減ったこと だった。

最初の blog-manager は、何をどう書けばいいか分からなくて、試行錯誤にかなり時間がかかった。
でも今は、まず

読む
加工する
確認する
保存する

という骨組みを置いて、そこに

何を読むか
どう加工するか

を埋めていく、という作り方ができる。

ワークフローを分けるかどうかも、
「途中で止めたい使い方があるか」
で判断できるようになった。

スキルの設計は、プログラミングみたいな厳密さまでは要らない。
でも、自分なりの型があると、毎回ゼロから考えなくて済む。

AI に手順を渡すための文章を書いているだけなのに、気がつくと自分の作業の構造そのものが整理されている。
これは、スキルを作る前にはあまり予想していなかった副産物だった。

まとめ

Cowork のスキルを複数作ってみて気づいたのは、結局どのスキルも

「読む → 加工する → 確認する → 保存する」

という同じ流れで動いている、ということだった。

そして、最初に一番迷った ワークフローの分け方 は、
「途中で止めたい単位 = ワークフローの単位」
というシンプルな基準に落ち着いた。

型が見えてからは、新しいスキルを作るのがかなり楽になった。
でもその型は、最初の1本で詰まって、2本目で
「あれ、これ同じだな」
と気づいて、3本目でようやく確信する、という順番でしか見えてこなかった。

作ってみないと分からない。
今のところは、その感覚がかなり正直なところだと思っている。

・自分の作業フローをCoworkのスキルにしてみたら、習慣の言語化を迫られた

・Coworkを使い始めて最初に詰まった3つのこと

2026年3月29日日曜日

AIに「自分」を渡すファイルを作ったら、毎回のセッションが変わった

・AIに「自分」を渡すファイルを作ったら、毎回のセッションが変わった

AIを使い続けていると、だんだん気になってくることがある。
作業の内容は積み上がっていくのに、AIへの自己紹介は毎回ほぼゼロから始まる、ということだ。

自分はどんな仕事をしているのか。
今どんな作業を進めていて、何を優先しているのか。
どういう道具や環境で動いているのか。

そのへんを毎回説明していると、地味に時間がかかる。
しかも、ある日は詳しく書き、ある日はかなり省略する。
渡す前提がそのたびに少しずつ違うと、返ってくる整理や提案の粒度も微妙にブレる。

これは一度整理した方がいい。
そう思って作ったのが claude_context.md だった。

作ろうと思ったのは、説明を減らしたかったからというより、前提の渡し方をそろえたかったから

きっかけは、「毎回説明するのが面倒だった」だけではない。
どちらかというと、毎回同じ形式で前提を渡せるようにしたかった という方が近い。

AIに何かを任せるとき、前提情報の渡し方がセッションごとにバラバラだと、返ってくる結果もバラつきやすい。
特に、継続して整理したい作業や、あとから見返したい記録系の作業では、このブレがじわじわ効いてくる。

その場その場で説明を組み立てるのではなく、最初から決まった形で渡せるファイルがあれば、AIへの依頼はもっと安定するはずだと考えた。

何を入れるかは、思ったより時間がかかった

claude_context.md に何を書くかを決めるのは、思っていたより難しかった。

あれもこれも入れたくなる。
でも、情報を盛りすぎると読み込みが重くなるし、更新も面倒になる。
逆に削りすぎると、文脈ファイルとしての意味が薄くなる。

最終的には、AIが作業を始めるために必要な最低限の文脈 に絞ることにした。
今はだいたい次のような内容を入れている。

基本プロフィール
仕事、PC環境、そのほか作業前提になる情報
現在進行中の作業やプロジェクト
それぞれの現在地と次のアクション
AI活用方針
どう使うか、どこまで任せるか
確定済みの主要方針
あとからブレると困る判断の抜粋
保管場所の構成
どこに何があるかの全体像

これを1ファイルにまとめて、セッション開始時に読ませるようにしている。

「AIに覚えさせる」より、「自分が渡す」と考えた方がうまくいった

このファイルを作る前は、どこかで
「AIがもっと覚えてくれたら便利なのに」
と思っていた。

でも実際に運用してみると、発想は逆の方がうまくいくとわかった。
AIは毎回リセットされる。そこは前提として変わらない。

だったら、記憶してもらうことを期待するより、自分の側で文脈を管理して、必要なときに毎回渡す 方が確実だった。

その方がコントロールもしやすい。
何を渡していて、何を省いているかが自分でわかる。
しかも、ファイルを更新するたびに「今の自分の状況」が少し整理される。

作業が進んだら書き換える。
方針が変わったら更新する。
この更新作業自体が、自分の現在地を確認する機会にもなっていた。

使ってみて、一番変わったのは立ち上がりの速さだった

一番変わったのは、セッションの立ち上がりだった。

以前は、まず「今何をやっているか」から説明し始める必要があった。
今は claude_context.md を渡せば、そこからすぐ本題に入れる。

説明に使っていた時間が、そのまま作業時間になった感覚がある。

もうひとつ変わったのは、AIへの依頼の精度だ。
前提がそろっていると、返ってくる提案や整理の質が安定しやすい。

何も知らない相手に毎回説明するのと、
自分の状況をひと通り把握した前提で入るのとでは、やはり違う。

まとめ：文脈はAIに期待するより、自分で持って毎回渡した方が安定する

AIとやり取りを続けていると、どうしても
「セッションをまたいで覚えていてくれたら楽なのに」
と思う場面が出てくる。

でも今のところ、自分には
文脈は自分で持って、必要なときに毎回渡す
という形の方が合っていた。

claude_context.md は、そのための一枚だ。
完成形というより、使いながら育てていく前提のファイルだと思っている。

今のところ、これがあるかないかで、毎回の作業の入りやすさはかなり違う。
AIに何かを覚えてもらう仕組みを探すより、まずは自分の文脈を自分で管理する。
その方が、少なくとも今の自分の運用では安定している。

自分の作業フローをCoworkのスキルにしてみたら、習慣の言語化を迫られた

・自分の作業フローをCoworkのスキルにしてみたら、習慣の言語化を迫られた

Coworkを使っていると、同じような頼み方を何度もしていることに気づく。

ブログのネタを出してもらう。
その中から1本選んで、下書きを作ってもらう。
必要ならObsidianに保存する。

一つひとつは大した作業ではないけれど、毎回最初から説明するのは地味に面倒だった。
それであるとき、「この流れごとスキルにできないか」と思って試してみた。

実際にやってみると、スキルを作ること自体より、自分が普段どうやっているかを言葉にする方がずっと大変だった。

スキルを作るには、「自分がどうやっているか」を説明しないといけない

スキルというのは、ざっくり言えば
「こう頼まれたら、こういう順番で動く」
をあらかじめ決めておくものだと思っている。

Coworkにブログ管理系のスキルを作れないか相談したとき、最初に詰まったのはここだった。

たとえば、

公開済み記事のリストはどこで管理するのか
下書きはどこに保存するのか
アイデアと下書きをどう分けるのか

そういうことを聞かれる。
見れば当たり前の質問なのに、これが意外とすんなり答えられなかった。

Obsidianで管理したい気持ちはあった。
でも、具体的にどのファイルに、どういう形で持つのかを改めて聞かれると、思ったより決まっていなかった。

「なんとなくやっている」は、スキルにならない

今までのブログ運用は、かなり「なんとなく」の積み重ねで回っていた。

ネタが思いついたらメモする。
書けそうなら下書きを起こす。
書き終わったらBloggerに貼る。

流れとしては一応あったけれど、
それがどこに保存されていて、いまどの状態なのかまできちんと管理できていたかというと、正直かなり怪しかった。

スキルにしようとすると、その曖昧さを放置できない。

どのフォルダに保存するのか
アイデア一覧はどこに置くのか
下書き本体は別ファイルにするのか
公開済みの記録はどこに持つのか

こういうことを一つずつ決めていく必要がある。
やってみると、自分の運用の曖昧な部分がかなり見えてきた。

言語化しようとして、初めて「決まっていなかった」と気づく

一番時間がかかったのは、保存先の設計だった。

最初は「AI_workspace に置けばいい」とかなりざっくり考えていた。
でも実際に考え始めると、それではあとから見返しにくい。

アイデア一覧と、記事ごとの下書き本体は分けた方がいい。
そう考えて、最終的には

blog_ideas.md で一覧管理
blog_draft_〇〇.md で記事ごとの下書き管理

という形に落ち着いた。

今振り返ると、この整理はスキル化を考えなければ、たぶん後回しのままだったと思う。
「どこかに保存してある」で済ませて、そのたびに探す、という運用を続けていた気がする。

スキルを作ろうとして、運用の土台まで見直すことになった

スキルが形になってからは、ネタ出しや下書きの流れをかなり短く呼び出せるようになった。

ただ、実際にはそれ以上に、自分の中の運用が前よりはっきりしたことの方が大きかった。

何が公開済みで、何がアイデア段階で、何が下書きなのか。
その状態が、少なくとも前よりは見えるようになった。

スキルを作るために始めたはずなのに、やっていたのは結果的に
情報整理の土台を作り直す作業
でもあったんだと思う。

まとめ：スキル化は、自分の習慣を棚卸しする作業でもある

Coworkのスキル機能は、繰り返し作業をまとめるためのものだ。

でも実際に触ってみると、その前に必ず必要になるのが、
自分は何を、どういう順番でやっているのかを言葉にすること
だった。

そこがいちばん難しくて、いちばん時間がかかった。
ただ、その工程を通ると、スキルができるだけでなく、自分の運用も少し整理される。

「なんとなくやっている」を言語化するきっかけとして、スキルを作ってみる。
これは思っていた以上に意味のある作業だった。

[Coworkを使い始めて最初に詰まった3つのこと]

[AIに記事を丸投げしないために、役割分担を考えるようになった]

[AIで稼ぐ前に、自分用の第二の頭を作りたい]

2026年3月27日金曜日

Coworkを使い始めて最初に詰まった3つのこと

・Coworkを使い始めて最初に詰まった3つのこと

AIと一緒に作業できると聞いて、Coworkを使い始めた。

便利だとか、作業が速くなるとか、そういう話は前からいろいろ見かけていた。実際、それ自体はたぶん間違っていないと思う。
ただ、自分の場合は、最初からスムーズに使えたわけではなかった。むしろ、使い始めの数回は普通に詰まった。

紹介記事はたくさんあるのに、「最初ここで困った」をそのまま書いた話は意外と少ない気がしたので、今回はそのへんを自分の記録として残しておく。

1. ファイルがどこに保存されるのか、最初はまったくわからなかった

最初にいちばん戸惑ったのはこれだった。

Coworkに何かを頼んで、ファイルを作ってもらう。
すると「できました」「保存しました」と返ってくる。
でも、その保存先がどこなのかがわからない。

自分のパソコンの中なのか、どこか別の場所なのか。セッションが終わったら消えるのか、そのまま残るのか。
今から見るとかなり基本的な話だけど、使い始めた直後はそこが全然つかめていなかった。

このへんが曖昧なままだと、「作ってもらったはずなのに見当たらない」が普通に起きる。
自分も最初は、できたと言われたのに、どこを見ればいいのかわからず少し混乱した。

あとから理解したのは、最初に作業フォルダを選ぶのが前提だということだった。
Coworkは、その作業フォルダの中で動いて、そこに出力してくれる。
逆に言えば、その前提を知らないまま使うと、「どこに行った？」が起きやすい。

今は、とりあえず最初に作業フォルダを確認してから始めるようにしている。
それだけで、保存先まわりの混乱はかなり減った。

2. 操作より先に、「何を頼めばいいか」で詰まった

次に詰まったのは、操作そのものよりも、何をどう頼めばいいのかの方だった。

なんとなく「こうしたい」はある。
でも、それをそのまま投げても、こちらが思っている形で伝わるとは限らない。

この感覚がはっきりしたのは、最近、上の指示や管理方法をスキル化できないかCoworkに投げたときだった。
やりたい方向自体は自分の中にあったけれど、「何を固定したいのか」「どこをテンプレ化したいのか」が、自分の頭の中ではわかっていても、依頼文としてはまだ曖昧だった。

AIに頼むときは、つい「いい感じにまとめてほしい」とか「うまくやってほしい」に寄りがちになる。
でも、その言い方だと、返ってくるものも広くなりやすい。
大きく外れているわけではないけれど、自分がほしかったものと少しズレる、ということが起きやすかった。

使い始めてから少しずつわかってきたのは、やってほしい作業と最終的にどうなってほしいかを分けて書いた方が伝わりやすいということだった。

たとえば、

何を整理したいのか
出力は何に使うのか
どの形式でほしいのか
何を避けたいのか

このあたりを最初に出しておくと、かなりズレにくくなる。

便利なツールというより先に、まず「依頼の出し方に慣れる必要がある」と感じたのは、このあたりだった。

3. 意図と違う結果が返ってきたとき、どう直せばいいのかわからなかった

もうひとつ詰まったのが、返ってきた結果が少し違ったときの修正のさせ方だった。

最初のうちは、何か違うと思っても、「じゃあ何をどう言い直せばいいのか」がわからない。
全部やり直してもらうべきなのか、それとも一部だけ直してもらうべきなのか、その感覚がなかった。

これは使ってみて少しずつわかったことだけど、全部まとめて直そうとするより、ズレている箇所を分けて伝える方がうまくいきやすい。

たとえば、

方向性は合っている
でもここだけ違う
この部分は残したい
ここは別の形にしたい

というふうに、差分で頼んだ方が修正しやすい。

人間相手でも、「何か違う」とだけ言われても直しにくい。
Coworkも同じで、全部を曖昧に戻すより、「どこを残してどこを変えるか」を切り分けた方が精度が上がりやすかった。

このあたりは、使う前はツールの性能の問題だと思っていたけれど、実際にはこちらの返し方の問題もかなり大きかった。

まとめ：最初の詰まりは、だいたい「仕組み」か「伝え方」に分かれる

使い始めてしばらく経ってから振り返ると、最初の詰まりはだいたい2つに分けられる気がしている。

ひとつは、ツール側の仕組みをちゃんと理解できていなかったこと。
たとえば、作業フォルダや保存先の感覚はその典型だった。

もうひとつは、自分の伝え方がまだ固まっていなかったこと。
何をしてほしいのか、どういう完成形を求めているのか、意図と違ったときにどこを直してほしいのか。
そのあたりが曖昧だと、便利さより先にズレの方が気になりやすい。

もちろん、最初から全部うまくいくわけではない。
でも、「最初に詰まりやすい場所」がわかっているだけでも、入り方はかなり変わると思う。

今は少なくとも、

最初に作業フォルダを確認する
依頼は「作業内容」と「着地点」を分けて書く
修正は全部やり直しではなく差分で頼む

この3つを意識するようになって、だいぶ扱いやすくなった。

便利さそのものより、まずはこのへんでつまずかないことの方が大事だったな、というのが今の実感です。

2026年3月23日月曜日

ClaudeがObsidian運用とかなり相性がいいと感じている話

・ClaudeがObsidian運用とかなり相性がいいと感じている話

はじめに──検索が強いAIだけでは足りなかった

AIに何かを聞く時、多くの人がまず期待するのは「調べてくれること」だと思う。
最新の情報を拾ってきてくれたり、検索の手間を省いてくれたり。自分も最初はそこから入った。

ただ、しばらく使っているうちに、調べものとは別の用途でAIが欲しくなる場面が出てきた。
手元にあるメモや文章を整理したいとか、考えをまとめる相手が欲しいとか、そういう場面だ。

そこで使いやすいと感じるようになったのがClaudeだった。

検索ではなく、「整理」に向いていると感じる

正直に言うと、Claudeは検索や情報の自動収集ではChatGPT PlusやGeminiより弱い印象がある。
外から情報を拾ってくる用途なら、他のAIの方が向いていることが多い。

ただ、その代わりに、手元のメモや長文を整理しながら考える用途ではかなりしっくり来る。
単に「要約して」で終わるのではなく、文脈を踏まえた上で構造を提案してくれたり、「この方向性どう思う？」みたいな相談にも付き合ってくれる。

自分の中では、Claudeは外から情報を拾う役というより、
すでにある情報を使って考える役 に近い。

Obsidianとの組み合わせがかなり大きい

自分はObsidianというローカルで動くノートアプリに、日々のメモやアイデアをかなり溜め込んでいる。
読んだ記事の感想、仕事の検討メモ、思いついたことなど、雑多なものがかなり多い。

この溜めたメモをClaudeに貼って、「これ、どう整理したらいい？」「この中で優先度が高いのはどれだと思う？」と聞けるのが、自分の運用ではかなり大きい。

Obsidianの中身を前提に壁打ちできるので、毎回ゼロから説明しなくていい。
ここがかなり楽だと感じている。

他のAIでもできなくはないと思うけど、Claudeは情報量が多い時でも比較的最後まで崩れにくい感覚がある。
途中から急に雑になった感じが出にくい、という言い方の方が近いかもしれない。

情報量が多い場面でも、比較的崩れにくい

この感覚は、趣味の競馬予想でも少し似たものを感じている。

競馬は1日に3場36レースが行われることがあって、それぞれに出走馬のデータや条件がある。
情報量としてはかなり多い方だと思う。

こういうものをまとめて見せた時、Claudeは全体を見ながら整理してくれる感じがある。
もちろん、完全に漏れがないと言いたいわけではない。そこまで言い切るつもりはない。

ただ、自分の感覚としては、他のAIと比べて情報量が増えても比較的崩れにくい。
このあたりは、かなり助かっている。

おわりに──手元の情報資産を活かす役として

Claudeは、外から情報を拾ってくるAIというより、手元にある情報資産を整理して活かすためのAIとして使うのが合っている。
少なくとも今の自分の使い方ではそう感じている。

Obsidianにメモを溜めて、それをClaudeに渡して整理や相談をする。
今の自分のAI運用の中心は、この流れにかなりある。

派手さはないけれど、地味に効いている使い方だと思う。
もちろん、Claudeもアップデートで変わっていくだろうし、他のAIがこの領域で強くなる可能性もある。

それでも今の時点では、
手元の情報を整理する相手としてはClaudeが一番しっくり来ている
というのが、自分の正直な感想だ。

登録: 投稿 (Atom)