Beads を約 1 か月使って分かってきた Beads の扱い方〜優先度判断と notes 運用〜
Hiroba による自動要約
AI コーディングエージェント向け課題管理ツール Beads の 1 か月の運用経験から、依存関係と優先度の登録により エージェントが次のタスクを選びやすくなった一方、notes への追記で古い情報が蓄積する問題が浮上した。対策として notes を履歴ではなく現在状態のスナップショットとして扱い、古い情報は bd update --notes で統合するルールに変更。失敗や判断過程は別途レポート化、繰り返し必要な知見は永続メモリで管理している。
読んで良かったら、シェアしてみてください。
同じタグの記事が他に 3714 件あります。
関連する記事
同じタグの記事
社内文書AIにベクトルDBは要らなかった — 全文投入で本番運用した設計と限界
Zenn社内マニュアルをAIに参照させる際、一般的なRAG（ベクトル検索）ではなく、マニュアル全文をプロンプトに毎回投入する構成を採用し、2社のSlackボットで本番稼働。トークン数計算とプロンプトキャッシュの活用により、ベクトルDB不要で運用が壊れにくく、表の断片化や検索漏れの問題を排除できた一方、入力量に正比例したコスト増加が課題。
朝の問題が難しい原因は難易度ではなく初見出題だった——予習ルーティンを8日間運用した結果
Zenn朝のメイン課題が重く感じた原因を調査したところ、難易度ではなく前夜の四肢選択と朝の記述式という問題形式の違いが原因だった。対策として夜のルーティン末尾に予習フェーズを追加し、翌朝の設問を前夜に生成・講義することで初見を避けるよう設計。8日間の運用で午前I演習の正答率は69.1%から75.0%に改善。Agent間の状態受け渡しでは、データ構造より「両者が同時に触れる共有ストレージ」の制約を優先すべき、という実装上の教訓も得た。
Qiita コンテスト全敗の診断：社内実験レポートを外部向け記事と誤認していた
QiitaQiita「ai& Inference」コンテストに投稿した3記事が全て落選。著者が5つの異なる AI に受賞記事13本と自分の記事を比較分析させたところ、原因は誠実さではなく「モデルや設定そのものを検証する社内実験レポート」になっていたこと。受賞記事は読者の具体的な困りごとを解く「道具」としてモデルを扱っていたのに対し、著者の記事は検証対象そのものが主題になっていた。この構造的ズレから生じる3つの症状（冒頭が方法論から始まる、検証が内部で閉じる、問いかけで締める）と対策を定式化。
Finding Unknownsを組織に — Claude Fable 5とナレッジグラフ
ZennAnthropic の Thariq Shihipar 氏が公開した「Finding your unknowns」が話題になっている背景と、組織での実務への応用方法を解説。Claude Fable 5 時代は長いプロンプトより「自分が何を知らないか」を先に洗い出す方が成果を左右しやすく、個人完結型ではなく複数部門が絡む業務では、AI に正解を出させるのではなく「会議のたたき台」を作ることがゴール。盲点の洗い出し（Blind Spot Pass）と構造化インタビュー（Structured Interview）の具体的な手順を営業→オンボーディングの例で実装可能な形で提示。