はてなブックマーク

Claude Code をブラウザから操作できるクライアントを作りました。 過去の Claude Code セッションのログを確認したり、Resume するのに便利でかなり捗るようになったので紹介します！ 作ったもの Claude Code の会話ログファイルは ~/.claude/projects/<project>/<session-id>.jsonl に JSONL 形式でリアルタイムに書き出されています。 作ったのはこのログファイルをリアルタイムにパースし、ヒトに読みやすい形で表示するビュワーです。実際にチャットを送ってタスクを進めることもできます。 見てもらうのがわかりやすいと思うのでデモを見せます: 見て分かる通り プロジェクトごとのセッション一覧の確認 ログファイルとリアルタイムに同期する、読みやすいセッションのビュワー ツールの in/out や thinking が展開表

こんにちは！株式会社エス・エム・エスでエンジニアをしている @_kimuson です。 今回は、社内のプロダクト開発で利用しているデザインシステムを MCP 化して提供し、社内のデザインシステムを活用した自然言語によるコーディング環境を整備したので、事例を紹介します！ デザインシステムの MCP 化とは 先日 Ubie さんが、社内のデザインシステムを MCP 化することで、UI 実装を効率化した事例を紹介していました。 簡単に自分なりの解釈をまとめると Figma の情報を取れる MCP を利用することで Figma の再現はかなりしやすくなった しかし、デザインシステムとの統合が難しい。<button style="font-size: 20px"></button> ではなくデザインシステムのコンポーネントとトークンを使って <Button textStyle="regular"><

退屈な開発をサボりたくて 自律稼働する Devin のような LLM Agent を Vercel AI SDK, mastra 辺りのエコシステムで自前で作ってみていたので知見を紹介します。 開発用の Agent に限らず、これから TypeScript エコシステムで Agent を組もうとしている人の参考になれば幸いです。 具体的な SDK の利用方法などは扱わず、技術選定やハマりがちだったポイントにフォーカスして書いていきます。 TypeScript エコシステムでの SDK の選定 まず、プログラムから LLM をさわろうと思ったら SDK を使うのが手っ取り早いですが、複数のオプションがあります。 OpenAI や Anthropic など特定のプロバイダの SDK を使う 公式提供で安定していて使いやすい 一方、モデルを差し替えたり、特定の用途に限って別のプロバイダのモデルを

tl;dr 去年tfactionを導入しようとしましたが、試行錯誤ののち以下の点を重く見て結局導入は見送りました。 導入のためのドキュメントがまとまっていない 構造が複雑すぎる unix哲学に沿っていない(直交性がない) 注意事項 本記事は導入しなかった話という内容の記事ですが、tfactionを全否定したりFUDをする目的のものではありません。 あくまで私達の環境とマッチするか検討して最終的に導入しなかった事実と、そこに至った過程・考えを書くことで、私と同様にtfactionの導入を検討している人の参考になったらと思い書いております。 なので、この記事を元にtfactionは全くだめだといった曲解や制作者への攻撃のために引用しないでください。 そもそもtfaction自体OSSで制作者の個人的な努力の成果物を無償で使わせてもらっており、そこについては感謝しかありません。さらに言えば、今回

こんにちは！ みなさんはコーディングで LLM は利用していますか？ 昨今は Cursor だったり、v0 だったりとコーディングを支援する LLM を活かした製品が続々と登場しています。 こういった製品は特定の用途に最適化されていて便利な一方、用途ごとに別の製品を利用するのは LLM を扱う都合上、気になる点もいくつかあります。 コスト面: LLM を裏で扱う都合上、サブスクにせよ従量課金にせよ一定の費用がかかってくる 例えば、3製品をサブスク契約してそれぞれLimitの1/3だけ利用する場合、かなりコスパが悪く感じる 従量課金でも、気をつけていないと費用が高額になりやすい オプトアウト等のポリシー面: 製品ごとに「学習利用されないか？」等を調査する必要がある 職業エンジニアが利用する場合、会社でガイドラインや利用申請が義務付けられていることもあるでしょう。製品ごとに都度そういった壁を突

ワークスペースを利用している TypeScript プロジェクトの開発をしているとき、共通パッケージの依存解決の方法には 素直に build 成果物を参照する exports フィールドで build 前の TypeScript ファイルを直接参照する 等いくつかの選択肢があります。 このエントリでは、それぞれのやり方での制約や、開発体験の良し悪し等を比較して状況に応じてどういうアプローチを採用するのが良いか考えてみます。 補足資料 上記のスクラップで調べたことがベースになっています。 課題の整理 典型的な Full-Stack TypeScript なモノレポ構成を考えてみます: my-project/ ├── apps/ │ ├── frontend/ # フロントエンド │ ├── backend/ # バックエンド ├── packages/ │ └── shared/ # 共通パ

それぞれが折りたたまれていてコメント全体がコンパクト リソースの数が増えてもコメントが縦へ長くなることはありません。 開けばこのように表示されます。 危険な操作(削除・更新)があったときにわかりやすい 削除や更新があった場合は画像のようにその部分だけは折りたたまず表示してくれます。 日本語なので読みやすい(日本人にとって) いい感じのコメントにするための tfcmt.yml 基本的に公式ドキュメントのDefault Configurationを日本語化して上記の修正を加えただけです。 なので、もとの英語表記がいいとか、特定の機能だけ取り込みたい、という方は以下と公式のDefault Configurationでdiffを取ると特定の機能だけ取り込みやすいと思います。 embedded_var_names: [] templates: plan_title: "## {{if eq .Exi