はてなブックマーク

前回のあらすじ 仕様駆動開発をClaude Codeで扱える「Spec Kit」で動かした。 Claude CodeにSpec機能を付与できるのは良いが、過程で重厚長大なドキュメントやタスクが生まれてしんどい印象があった。何でも中規模～大規模開発くらいの大袈裟になってしまう。そんな時、ふと思い出したVibe Kanbanとの組み合わせに気づいた。 Specで作られるファイルが大袈裟になってもタスクを個々に分割してカンバン管理すればいい。触ってみたかったVibe Kanbanのチュートリアル代わりに試してみる。 Vibe Kanban Vibe Kanbanは、主にCLI型のコーディングエージェントをGUIからカンバン管理で操作できるダッシュボードを提供するOSS。ライセンスはApache License 2.0。 CLI型のClaude CodeやCodexなどのエージェントをGit Wo

はじめに 何番煎じかもう分からないけどSpec Kitを触る。 Spec Kit Spec Kitは、GitHubが2025年9月に発表した、仕様駆動開発（Spec-Driven Development）を支援するオープンソースのツールキットです。2025/9/9時点ではClaude Code/Gemini CLI/GitHub Copilotに対応している。 そんなんAWSも出してなかったっけ? と気づいた方は正しくて、Kiroというプロダクトのコア機能がSpecという機能でSpec-Driven Developmentはおそらくそれが初出ですね、はい。 ちなみにKiroの大まかなSpecでのフローはこの通り。ウォーターフォールの再発明、または「螺旋」的な技術の揺り戻し。 パクリかどうかみたいな話をする気はなくて、逆にもっと混乱させる話もすると、Clineでも/deep-planning

AWSからエージェント型IDEのKiroが出ました。CursorやWindsurfの競合製品と思われます。ややこしいのですがAWS 〇〇みたいにAWS製品としての位置付けではないらしい。 本当にさっき(2025/07/15 00:30)登場したので眠いです、、簡単に知りたいところを確認してみます。雑メモなので賞味期限が数日しかない Kiroのコンセプト 基本的な機能は揃ってそうで、MCPとかは全然繋がる。 Agent FAQを読むと、Vibe Codingをプロ仕様に支援してスペック駆動開発（Spec-Driven Development, SDD）で進めるCoding Agentが主体のIDEとのこと。 Kiroは、仕様駆動開発によってプロトタイプから本番環境への移行を支援するエージェント型IDEです。 スペックを使った開発は、バイブコーディングの楽しさを維持しながら、いくつかの限界を克

はじめに Claude CodeをGitHubで動かせるClaude Code Actionsが出ましたね。 私はAnthropicのAPIをBedrock経由でアクセスしたいので、自分用の手順を用意します。 1. Claude Code Action いきなりですが、記事を書くために調査していたら、既に他の方の記事が出ていたので書くことが無くなりました… せっかくなので利便性方向で差別化していきますか…… 使用感 使用感を先にざっくり書くと、GitHubのiPhoneアプリからVibe Codingができる。 このように音声入力で雑に指示を出す。 するとCIが発火し、Claudeが実装した結果を返信してくれる！ さらに「Create PR→」をクリックすると下書き済みのPullRequestの画面へ行くので、クリックするだけでPRを発行できる。(この辺自動でしてくれてもいいんだけど、便利

とりあえずClineにClineのリポジトリを読んでもらう Cline.botへのデータ送信分析レポート 概要 このレポートでは、Cline VSCode拡張機能がどのようなタイミングでCline.botにデータを送信するかについて、コードベースの詳細な分析結果をまとめています。特に、Cline以外のプロバイダー使用時にデータが送信されるかどうかに焦点を当てています。 1. テレメトリーデータの送信 src/services/posthog/telemetry/TelemetryService.tsで実装されている機能により、PostHogを通じて匿名の使用状況データが送信されます。 重要な特性: テレメトリーはユーザーがオプトインした場合のみ有効 VSCodeの全体的なテレメトリー設定が無効の場合、Clineのテレメトリーも自動的に無効 送信される情報は以下に限定: タスクの開始・終了タ

文脈 zenncafeというイベントで先日登壇させていただきました(宣伝) イベントのメインコンテンツとして「生成AI時代のテックブログプラットフォームの在り方(超訳)」のような座談会があって有意義でした。レポはこちらの記事でも書かれていますね。 私も自分なりに「なぜ技術記事のLLM生成は問題になり得るのか」を整理してみます。 技術記事のLLM生成に関する問題 プラットフォーム目線の問題もあるのですが、話が発散するのでユーザ視点で考えます。 読み手側 一言でいうと「LLM作成の記事の多くはクオリティが低く、読んだ時間が無駄になる」という問題があるでしょう。ややこしい点として、人間の書いた記事もクオリティが低い記事の方が、残念ながら多いです。その差は何？と考えたときに、以下のような問題だと認識しています。 従来は、文章力の稚拙さや用語の使い方の誤りなどで「足切り」ができていたが、LLM生成で

はじめに Vibe Coding × 従量課金制APIの肌感覚に誤りがあったので、正しい感覚を共有するために書く。Amazon Bedrock Prompt cachingが高いという話ではないです。 Vibe Coding Vibe Coding自体がバズワード気味なので、認識が合うか自信がないのだが、”DevinやCline/Claude CodeでAIがサジェストした仕組みを最大限尊重してプロダクト/システムを作成する開発方式”だと私は思ってやっている。 余談だが、これまでは全然Vibe Codingできていなかった(下記資料) Claude CodeでのVibe Coding 公式を参考にInstall。

はじめに MCPの新しい仕様が策定されたらしい。 MCPにはOpenAIも乗っかるようだし理解しなくてはいけないのだが、申し訳ないことにMCPについて解説できるほど詳しくない。 とりあえず今回の差分をNotebookLMに入れて聞いてみたいというモチベーションで、作業手順をメモする。 MCP仕様の格納場所 続くツイートで、MCPの仕様がこのリポジトリに格納されていることがわかる。 中身はこんなん。 tree docs/specification docs/specification ├── 2024-11-05 │ ├── _index.md │ ├── architecture │ │ └── _index.md │ ├── basic │ │ ├── _index.md │ │ ├── lifecycle.md │ │ ├── messages.md │ │ ├── transport

これなに これを書いた後にClineが盛り上がってきたので、また書きたくなった。二番煎じをやめろ。 大枠では変わってないので軽めのTips集です。 前回から変わった点 一か月前(2025/2/3)に書いた時から状況が変わっている ハイブリッド推論モデルとして、Claude 3.7 Sonnetが公開(2/24) Clineのアップデート .clineignoreによる読み込み対象からの除外 @terminal, @gitによるコンテキスト理解の改善 MCP Marketplace mizchiさんの魂が震えた モデル選定(2025/03) 利用経験のあるモデルを主観的にランク付けしている。 Tier1(基本これでいい) Claude 3.7 Sonnet Tier2(サブ機) Claude 3.6 Sonnet Claude 3.5 Sonnet Gemini 2.0 Pro Tier3(

LLM時代のWebアクセスとは 世は大LLM時代。皆が元気にTavilyでWebクロールしたり、AI AgentでガンガンDeep Researchする時代は、人間用のWebサイトにえげつない負荷を与えているのであった。 そんな時に「仕様を1枚のテキストにまとめたよ！」みたいな情報が時々流れてくるが、これはLLMs.txtというらしい。恥ずかしながら仕様の存在を知らなかったので、勉強がてらにまとめてみる。 LLMs.txt? Answer.AI の Jeremy Howard 氏が2024/9/3に提案したのが発端のようだ。 LLMs.txtはLLM（推論エンジン）向けの課題を解決するための提案である。LLMのコンテキストウィンドウの制限に対応したり、不要なマークアップやスクリプトを削除し、AI処理に最適化された構造でコンテンツを提供できる。ということらしい。シングルファイルなのでCDNに

これなに 前から欲しかったCLIツールがあり、Clineに作らせることにした。 せっかくなのでClineのみで開発した肌感覚が欲しくて、結果として＄100かかった血の記録を残す。 前提 Fork版ではなく、本家のClineの話をする。 公式ドキュメントを読まずに突っ走ったので、現場ノウハウ的な内容ではある。 Amazon Bedrockでの費用感を試したかったので、以下のモデルを利用した。 Claude 3.5 Sonnet Claude 3.5 Haiku Clineの位置づけ Clineの基本的な知識及び2024年末までの状況は、この記事で理解できる。 .clinerules プロジェクト固有のシステムプロンプトは、Clineではclinerulesファイルに記述する。個人用のSetting >> Custom instructionsとは位置づけが異なる。 .clinerulesはル

はじめに LLMの支援が当たり前になった現在、オレオレツールを公開するハードルは下がり続けている。 私も以前からOSSコントリビュートはしていたが、Clineにより生産性を高められ、初のOSS公開に至った。(その後、既存のより良いPluginが見つかりArchiveした) 他にも諸々あり、自分の経験から表題の危機感をぼんやりながら書いてみる。 前提 Clineとはコーディングに特化したAI Agentを扱うことのできるVS Code拡張機能である。 本記事は、この記事の内容を踏まえている。 Clineの盛り上がり 2025年の年明けから現在、Clineの話題でTwitterが盛り上がっている。 もっとも2024年11月末時点でこの記事のために情報収集した時には、盛り上がりは限定的であった。 いま盛り上がっている理由として、下記の条件が揃い、追い風が吹いている状況が一因と想像できる。 1.

はじめに PythonでHTTPリクエストを大量に非同期で投げる方法を探していました。requestモジュールはどうも対応していない様子なので、aiohttpを使うしかないのか…？と諦めていたところ、どうやらHTTPXが良さそうなので、試してみました。 What's HTTPX? HTTPXはDjango REST frameworkや、Starlette、Uvicornと同様に管理しているEncode社が管理しているプロダクトのようです。 HTTPX is a fully featured HTTP client library for Python 3. It includes an integrated command line client, has support for both HTTP/1.1 and HTTP/2, and provides both sync and a

import { Hono } from "hono"; import { handle } from "hono/aws-lambda"; import { logger } from "hono/logger"; import { HumanMessage } from "@langchain/core/messages"; import { BedrockChat } from "@langchain/community/chat_models/bedrock"; const app = new Hono(); app.use(logger()); const Layout = (props: any) => ( <html> <head> <meta charset="UTF-8" /> <title>{props.title}</title> </head> <body>{pro

3. Hono × Lambda@Edge デモ用なので簡単な要件を設定してみます。 /hono/ -> /test/hono.html とルーティングする。 シンプルなBasic認証をかける。 viewer-requestに関連づけられたLambda@Edgeを以下のイメージで更新し、cdk deployを行います。 import { Hono } from 'hono' import { basicAuth } from 'hono/basic-auth' import type { Callback, CloudFrontRequest } from 'hono/lambda-edge' import { handle } from 'hono/lambda-edge' type Bindings = { callback: Callback request: CloudFrontR

これ何 この記事で話そうとした、AWS Lambda/Lambda@EdgeにおけるHonoの利用方法を紹介します。 Lambdaでwebフレームワークを扱う是非は、前の記事もあわせて読んでください。 対象読者 Lambdaにフレームワークを載せる運用に興味があるAWSユーザ AWS CDKでTypescriptを利用していて、バックエンドをサクッと書く方法を知りたいAWSユーザ 他のプラットフォームで既にHonoを利用している方は、公式ドキュメントと重複する点が多いことにご留意ください。 あなた誰 主にAWS界隈で活動しています。 HonoのContributerとして、AWS LambdaのAdaptorをメンテナンスしています。 HonoのContributerとして、Lambda@EdgeのAdaptorを提案し、以降もメンテナンスしています。 というわけで、少なくともAdapto

2023年のマイクロサービス事情 雑談から入ろう。 明言されることは少ないが、「マイクロサービス」には明らかにダメな検討過程と呼ぶべきものがある。 ここ10年のモダンなインフラ基盤で存在感のあるAWS、Kubernetes、etc...が採用しているから、推奨しているから採用。 チーム、部署、所属企業の分断がまずあり、そこを境界にとした「マイクロサービス」を採用。 サービスの特性やロードマップを整理せずに、拡張性が高そうだから。 こういう理由で採用するのは安直だよね。とさすがに2023年末では落ち着いていて、地に足のついた真面目な議論のできる状態だと信じている。（どれが私の経験談かは聞かないでほしい） 少しずつ本題に入る。AWS Lambdaはイベントドリブンなサービスである。それもあってマイクロサービスとの相性がいい。マイクロサービスとの相性が良く、モノリスがアンチパターンなのだ。という

Honoのミドルウェアは作れる Honoには様々なミドルウェアがある。公式のsrc/middlewareやhonojs/middlewareリポジトリにたくさんある。ということはHonoのミドルウェア、俺も自作できるんや…！と気づいたので、何か作ろうとおもった。 似ている位置づけのExpressのミドルウェアを調べていたところ、「helmet」が便利そうであることがわかった。 Helmet helmetとはExpressのミドルウェアで、こんな風に書くとセキュリティ系のヘッダーをいい感じにつけてくれる。 import express from "express"; import helmet from "helmet"; const app = express(); // Use Helmet! app.use(helmet()); app.get("/", (req, res) => {

はじめに bun installで生成されるBunのロックファイルはbun.lockbというバイナリファイルである。 公式を読むと性能向上のためにバイナリ化していることがわかる。 Why is it binary? In a word: Performance. Bun’s lockfile saves & loads incredibly quickly, and saves a lot more data than what is typically inside lockfiles. 困ること まさにこのツイートの問題で、Git管理したいのにバイナリが出力されるのは不便で、どうしよう? と実際の本番利用では困るだろう。 解決方法 案1. git diffで差分確認する 公式のページを読むと、どうやら設定追加でgit diffができるらしい。 bun install request g

はじめに よくAWSの仕事をするので、開発環境をAWS Cloud9(以下Cloud9)で用意することがある。 IAM Roleが使えるのでAWS内の開発は便利なのだが、そのままPythonで開発しようとすると、2023/05/27時点でこう表示されるので、ちゃんと開発環境作らなくちゃね。という気持ちになる。 久々にLangChainやLlamaIndexやらで盛り上がってるし、Python環境でも作るか！ と思い立った筆者。じゃあ何を準備すればいいんだっけ、と軽く調べただけでもpip, venv, pyenv, pipenv, poetryなどの選択肢がありすぎて、もうこの時点でげんなりする。Pythonのパッケージマネージャの周辺事情はずっと混沌としていたんだった…… ただ最近は比較的よさげなプロジェクトのRyeがあるので、今回はこれで環境を整えてみる。 Ryeとは 上で書いたような「

はじめに 前回の記事で紹介した通り、P2P型のVPNであるTailscaleは設定が簡単であり、非常に便利だ。 そんなTailscale ネットワークにAWS Lambdaを接続できるらしい。が、公式ドキュメントを読んでも今一つピンとこなかった。 比較的新しい機能ということもあって事例も見つからないため、試しに作って動かしてみた。 前提知識 AWS CDK Tailscale on AWS Lambdaはコンテナで動かすことを前提にしている。 AWS上で管理するコンテナイメージは通常ECRを利用するが、検証目的で作成・削除を繰り返す際に、中のコンテナイメージを削除するのが少々面倒である。 であるが、先日AWS CDK v2.70.0で追加となったRepository deletion機能を使えば、自動で削除できて便利だ。 cdk-docker-image-deployment CDKでEC

はじめに Tailscale、気にはなっていたのだけれど、この辺りのツイートを見て興味が出たので、自分でも手を動かしたのでメモ。 Sign Up 費用感はこの辺りを読むとわかりやすい。個人利用なら20台は無料で使えるので検証には十分ですね。 Personalプランのリンクから登録すればよい。 と言っても、細かいサインアップの手続きはなく、MS/Google/GitHubいずれかのアカウントで連携するのみ。※私はGitHubで連携した。 Usage デバイス登録(一台目、Amazon Linux2) 早速１台目を登録してくれということなので、近場にあったAmazonLinux2 on EC2(というかCloud9)へ導入する。 基本的に言われるがままにコマンド実行するだけで、VPNの知識は特に何も調べてないままエージェントが導入される。 デバイス登録(二台目、Windows Server)