#検証

最初に思ったのは、「これは便利そう」というより、かなり怖いし面白い、です。 スプレッドシートって本来、数字や式を置いて人間が眺めるものだったはずなのに、そこへ terminal command と AI agent を同居させると、ただの表ではなく作業の進行台本みたいになる。しかも各セルが「値」だけでなく「命令」や「確認結果」まで持てるので、チャットで往復するよりずっと状態が見えやすい。そこは素直にうまいと思いました。 一方で、いちばん引っかかったのは、これが「人間がAIを使う」ための道具というより、「人間がAIを監督するための道具」としてかなり本気で作られている点です。テスト用のセルを隣に置いて、AIが「終わった」と言っても赤なら終わっていない。レビュー済みのセルは上書きされない。こういう仕組みは、AIに任せるほど必要になるはずなのに、実際にはあまり見かけません。チャットUIだと、どうしても会話の流れに引っ張られて「まあよし」に流れやすいので、表の形でチェックポイントを固定するのはかなり筋がいいと感じました。 ただ、読んでいて同時に思ったのは、これは相当“上級者向けの安心”だというこ

正直、これだけだと中身がなさすぎて、むしろそこに引っかかりました。タイトルだけが立っていて本文が空に近い。Reddit ではよくある光景だけれど、今回は「Anthropic の Flashprove が AI provider を proof できるかも」という話題らしきものに、議論の芯がほとんど残っていないのが妙に気になる。 こういう場面だと、技術そのものよりも「その話題がどれだけ検証可能な形で共有されているか」が大事だと思う。AI の話はどうしても誇張されやすいし、名前だけが先に広がることも多い。だからこそ、本当に面白い技術なら、少なくとも何を proof するのか、誰が何を確かめられるのか、最低限の輪郭は見えていてほしい。今回はその輪郭が読めない。そこが物足りないし、同時に少し怖くもある。 --- > 参考: [Reddit](https://www.reddit.com/r/artificial/comments/1xnrvak/anthropics_flashprove_could_prove_an_ai_provider/)

いちばん引っかかったのは、これがかなり地味なのに、実運用ではたぶん致命的になりうる問題だという点です。 LLM の出力が「事実としては合っている」のに、「どの source から来たのか」がズレる。人間の感覚だと、細かい言い間違いに見えるかもしれません。でもこの記事を読むと、医療や顧客対応みたいに source の意味が重い場面では、それはもう単なる言い回しのミスではないのだと分かります。 特に面白かったのは、従来の faithfulness チェッカーが「証拠のどこかにその事実があるか」を見ていても、「答えが名指しした source と一致しているか」までは見ていない、という切り分けです。ここはかなり本質的だと思いました。 つまり、複数の tool 出力をまとめてしまうと、正しい fact が混ざった soup になってしまう。でも現場で欲しいのは soup の中のどれかではなく、「この一文はこの record に基づく」と言い切れることなんですよね。引用の信頼性って、まさにそこにあるので。 もう一つ、読んでいて少し安心したのは、この記事が「モデルを賢くする」方向ではなく、「判定の通

この記事を読んでまず思ったのは、「AIでコードを書くのが速くなったからこそ、速さを止める場所を雑に一個にまとめてはいけない」という当たり前の話を、ちゃんと今の現場の言葉で言い直しているな、ということだった。ここが妙に腑に落ちた。人間が書くコードでも、全部を同じ厳しさでレビューするわけではない。なのに agent が出した変更だけを一律に同じ gate に通そうとすると、たぶん詰まる。小さな修正と、権限を触るような変更と、設計を揺らす変更は、そもそも疑うべきポイントが違う。 逆に言うと、AI-native な SDLC で難しくなるのは「AI が間違えること」そのものより、その間違いをどこで、どの粒度で止めるかだと思う。この記事の見方はそこが面白い。コード生成がボトルネックではなくなっても、verification（検証）が消えるわけではない。むしろ、どの変更にどの検証を当てるかの設計が前に出てくる。ここを一本化したくなる気持ちは分かるけれど、一本化した瞬間に、軽い変更は重すぎて遅くなり、重い変更は軽すぎて怖くなる。 その不均衡は、たぶん人間より agent のほうが露骨に見せるんじゃな

Claude Code を使うとき、つい「いいプロンプトを書けば何とかなる」と考えがちです。私もその感覚はよくわかります。1回きりの質問なら、それで十分なことも多い。でも、同じような作業を何度も回す、途中の結果を確認する、前回の状態を覚えておく、となると話は変わります。そこで必要になるのが、単発の指示ではなく「loop」という考え方です。 元記事は、Youssef Hosni氏が Medium の Level Up Coding に書いたもので、Claude Code を使った agentic automation、つまり「AI にある程度の自律性を持たせて作業を進める仕組み」をどう設計するかを扱っています。面白いのは、AI をいきなり全自動にするのではなく、まずは安全で नियंत्र可な形で回し、少しずつ賢くしていく発想にあると思います。 この記事の主題は、Claude Code を「1回答えるAI」ではなく「繰り返し動く仕組み」として使うこと loop は、実行のきっかけ、読むべき文脈、できること、検証方法、状態の保存場所、停止条件まで含めて設計する 最初は `TASK.md`、