Claude Codeで「オウンドメディアのAI編集部」を構築した。人間が事業計画・役割・ワークフローを定義し、AIがSKILLとAGENTSを実装するという構造で立ち上げた。編集長の承認基準が厳しすぎてコンテキストを食い潰す問題と、出力された記事がAIらしくなってしまう問題が発生した。今回はその設計・実装・失敗・学びを整理する。
ZettelkastenをClaudeのRAG情報源として接続しようとしたとき、ノート間のリンクに意味がないとAIがネットワークを無制限にトラバースしてしまう。この問題の本質を検討し、それに対する取り組みとしての「型付きエッジ (relation-typed edges)」という設計アプローチについて整理する。この方法論により、使用トークン数は70%削減、エージェント数は67%削減、回答品質はほぼ同じか上がったという結論を得た。
技術者が抱きがちな「顧客はわかっていない」という感覚を、「思考限界」という概念で再解釈する。この問題はAIとの協働構造と本質的に同じであり、優れたアーキテクトはその思考限界を動的にずらしながら目的達成へとコーディネートすることができる。
Red Hat OpenShiftのDeveloper Sandboxを実際に触ってみた。サービスの集合体であるAWSと、Platform as a Productとしての統合されたプロダクトであるOpenShiftを比較しながら、その設計思想の違いと開発者体験について整理する。
ローカルLLM（Deepseek R1 0528 Qwen3 8B）でtemperatureとseedの設定がコード生成と俳句生成にどう影響するかを実験した。推論に使われる言語（思考言語）がアウトプットの質を大きく左右するという、予想外の結果が得られた。
ローカルLLM（LM Studio + Aider）でSpec Driven Developmentを実践しようとしたものの、モデルの推論性能とハードウェアの制約という二重の壁に阻まれた。その失敗の記録と、そこから得た学びをまとめる。結論から言うと、2026年時点で個人のMacBook M3 24GB環境においてローカルLLMでSpec Driven Developmentを実用するのは現実的ではなかった。本記事は、その失敗の記録である。
Slackと連携するチャットボットをAWS上に構築する過程で、設計を3回やり直した。その試行錯誤を通じて、RAGの本質的な役割、OpenSearchを中核に据えることのメリット、そして生成AI時代に人間に求められる「構造設計能力」について考えたことをまとめる。
GitHub Pagesで公開しているHugoブログに、ムームードメインで取得した独自ドメインを設定する手順と、ハマりやすいポイントをまとめました。
Zettelkastenを「思考の再利用装置」として機能させるには、情報の厳選が不可欠だ。精査済みの情報のみを格納し、走り書きや他者の意見（文献ノート）は別管理にしてノイズを排除すべきである。また、各ノートは将来の自分が見返すことを前提に、単体で理解可能な「原子性」を持たせ、リンクを通じた改善を繰り返すことが重要だ。管理単位を明確に分けることで、知の再生産に適した高い情報密度を維持できる。
Zettelkastenは「知の再生産」を支える仕組みだと考えている。原子的なノートを自分の言葉で蓄積・再構成することが重要で、AIにノート作成や構造操作を任せるとノイズが増え、思考の質が損なわれると実感した。