2026.10.06 · AI活用 · 学び

AIを使えているのか不安になって、
知識の棚をつくった日。

普段はAIを使って仕事をしている。でも、体系的に学んできたわけではない。いまの自分がどこまで分かっていて、何を知らないのかを、AIに質問してもらいながら棚卸ししてみた。

ちゃんと分かっているのか、よく分からなかった

普段からChatGPTやCodexは使っている。調べものをしたり、文章を整えたり、小さな仕組みを作ったり。使う中で必要になったことは、その都度調べてきた。

ただ、AIの変化は速い。「一回、体系的に勉強しよう」と思っても、教科書を最初から読む気にはなりにくい。読むそばから古くなりそうだし、それなら何かを作っていた方が身になる気がする。

一方で、最新の考え方を取りこぼしていないか、基本の穴が大きすぎないかという不安もあった。だからChatGPTに、いまの自分の背景に合わせてAI理解を確認する質問を出してもらった。質問は30個。最初は少し身構えたけれど、これは試験というより、頭の中の引き出しを一緒に開けていく時間だった。

声で答えると、考えかけの言葉も使えた

今回よかったのは、質問を画面で見ながら、答えを音声入力したことだった。考えがまとまっていなくても、「たぶんこう」「ここは怪しい」と話し始められる。フィラーも多かったと思うし、後から一語一句を検証したわけでもない。それでも、書き始める前に止まってしまうよりはずっとよかった。

会話モードは楽しいけれど、考えている途中で話が進んでしまうことがある。その点、質問を5問ほど並べておいて、順番に独り言のように答えるやり方は自分に合っていた。思考の下書きを、音声で置いていく感じ。

分かっていなかったのは「Agent」と「MCP」だった

最初に引っかかったのがAgentだった。自分の中では、ある程度振る舞いを決めたAIくらいの理解だった。でも、より近いのは「目標のために、状況を見ながら複数の行動を選ぶ仕組み」らしい。

言葉は知らなくても、やりたい動きは自然に考えていたらしい。逆にMCPは、画像生成などの拡張機能に近いものだと思っていた。実際には、AIが外部のデータや道具とつながるための共通の接続方法。たとえば、検索や予定確認といった機能を、複数のAIクライアントから同じ形で呼べるようにする規格だと聞くと、急に輪郭が見えた。

「AI用のUSB-Cみたいなもの」という例えは、かなりしっくりきた。名前だけ先に覚えるより、何と何をつなぐためのものなのかを知る方が覚えやすい。

92%正解でも、役に立たないことがある

もう一つ大きかったのが、AIを評価する話だった。精度が92%なら、かなり良さそうに見える。でも、重大な見逃しが8件あるのに「問題なし」とばかり答えて92%になっているなら、そのチェックには使えない。

ここで初めて、Accuracyだけでは足りない理由が腹落ちした。何を見逃したくないのか。間違って拾いすぎても困るのか。処理時間や費用はどうか。AIの良し悪しは、一つの点数で終わらせず、実際の失敗の重さまで含めて測る必要がある。

こういう評価の仕組みは、Evalsと呼ばれるらしい。人間が正解を確定したサンプルを用意して、変更のたびに同じ条件で試す。なんとなく便利だった、だけではなく、「前より良くなったのか」を確認するためのものだと理解した。

検索が外れたのか、答え方が外れたのか

RAGという言葉も、知識を検索してAIに渡す仕組みくらいには理解していた。でも、正しい資料が保存されているだけでは、正しい答えになるとは限らない。そもそも必要な資料を取り出せなかったのか。取り出した資料は合っていたのに、AIが読み違えたのか。この二つは分けて見ないと直せない。

前者は検索の問題、後者は生成の問題。検索語、タグ、日付、資料の分け方を見直すべきときもあるし、回答に根拠を添えさせたり、根拠がなければ「分からない」と言わせたりすべきときもある。AIが間違えた、で終わらせず、どの段階で外れたかを追う。これは自分のPKBを育てるときにも、そのまま使えそうだった。

自分で作ろうとしていた知識庫は、意外と筋がよかった

今回、少し安心した部分もあった。過去の会話をどう残し、あとで引き出すかという話になると、自分の考えはわりと自然に出てきた。

Rawを残すのは、要約だけにすると、AIが重要ではないと判断した情報が戻らなくなるからだ。あとで「そういえば、あのときどう考えていたんだっけ」と戻りたくなる。だから原文を残し、要約・タグ・日付・索引は上に重ねる。ObsidianのPKBを作ろうとしていた理由が、言葉として整理された。

ただし、知識には時間の問題もある。去年の方針と、今日の方針が違うことがある。「いつ書いたか」「いつの事実についてか」「いまも有効か」を分けて持つ。この考え方は、これからの自分の記録にも入れていきたい。

AIを使わない判断も、設計の一部だった

質問の中には、「この作業に生成AIを使うべきか」というものもあった。読み取りや転記のように、決まった処理で確実にできるなら、無理に生成AIを入れない。複数の資料を読み比べたり、過去の事例を探したり、言葉で相談に乗るところではAIが効く。数値計算で答えが一つに決まるなら、まずは計算の仕組みで処理する。

AIを使えるかではなく、AIを使う必要があるか。この問い方は、これからも大事にしたい。便利そうだから入れるのではなく、時間がかかるところ、属人化しているところ、ミスが痛いところを見つける。その上で、小さく試して効果を測る。

足りなかったのは、知識そのものより棚だった

30問を終えて、最初に思っていた「自分はAIを使いこなせていないのでは」という不安は少し変わった。実務で試しながら積み上げてきた感覚は、それなりに使えていた。ただ、LLM、RAG、検索、Agent、セキュリティ、評価といった地図がなかった。

地図がないと、自分がどこに立っていて、何が分からないのかが見えない。MCPやTool Callingを知らなかったことも、知識がゼロというより、名前と実感がまだつながっていなかったという方が近い。

体系的な勉強は、最初から全部を暗記するためではない。実践で得た知識に地図を与えて、空いているところを狙って補完するために使えばいい。自分には、そのやり方が合っていそうだった。

次に学ぶこと

• LLM基礎の体系化：Token、Context Window、推論、Sampling、Embeddingを、自分の使い方とつなげて理解する。
• RAGと検索：Keyword Search、Vector Search、Metadata、Hybrid Searchを、PKBの検索性に落とし込む。
• Agent / Tool Calling / MCP：AIが外部の情報や機能とどうつながり、どこで人の承認を入れるべきかを試作しながら学ぶ。
• Evals：便利そう、で終わらせず、正解例と失敗の重さを使ってAIを評価できるようにする。

次は、今回出てきた知らない言葉を、またChatGPTと対談するようにほどいてみたい。たとえば「MCPって結局なに？」から始めて、自分のPKBや日々の仕事でどう使えるかまで落とし込む。学びの記録も、完成した答えだけではなく、分からなかったところから残していこうと思う。

たぶん次に忘れることもある。それでいいと思う。分からなくなったら、この記事と元のメモに戻り、今の自分の言葉で説明し直せばいい。知識を一度きりの正解として持つより、何度でも戻れる場所を作る方が、変化の速い分野では役に立ちそうだ。