はてなブックマーク

この記事は 実践で フル AI コーディングするための考え方とノウハウを凝縮したものです。筆者が持ってるノウハウはほぼ全て書いたつもりです。 Algomatic アドベントカレンダー 12/8 です。 この記事は、必要となる前提知識・考え方と、実践ノウハウと、AI デトックスについての三段構成になっています。 注意事項: この記事は、実践で、本格的なプロダクト開発をフル AI コーディングするためのものです つまり、メンテナンス性がとても重要です フル AI コーディングとは、コーディングエージェントなどの AI のみでコーディングすることです。一部人間がちょっとした手直しをすることもあるかもしれませんが、基本的には AI に書かせます LLM とは何かを知ってる人向けの記事です Claude Code や Codex や gemini-cli などをコーディングエージェントと呼ぶことを知

2025年10月20日の僕が考えるAIコーディング（バイブコーディング）プロセスです。 個人的な結論としては、1ミリでも気に食わないコードを生成してきたら、そのタスクは最終的には破棄すべきというものです。「このコード気に食わない」「この設計気に食わない」の直感がAIコーディングで品質を維持する生命線です。 バイブコーディング時代ではコードレビューのお局ビリティが鍵です。 レビューに全時間を割こう。レビューに時間がかかりすぎるというより、レビューに時間をもっとかけるくらい 1ミリでも知らないことをなくそう 断片的なAIコーディングでいえば1年弱、本格的なコーディングエージェントを使い始めて半年以上の僕がたどり着いた結論です。 よろしければ、皆さんのTipsや感想も知りたいです。アップデートしていきたいところです。 前提 僕は実装だけじゃなくて、設計もさせることが多いです Codex使いましょ

この画像がすべてです。 Sonnetでは解決できなかったタスクを解決するため、Gemini 2.5 Proで、タスクを fire and forget して寝て起きたら、こんな感じになっていました！！！！ ロングコンテキストはお金がかかるのでAPI破産しないように注意しましょう（それはそう） Googleさんお願いですからOpenAIと同じ方式の自動プロンプトキャッシュ実装してください！ コーディングエージェントには金額ベースの予算上限が実装されるべき！ コストが下がらないと、コーディングエージェントでの1M contextはちょっと非現実的かもしれないですね！Google AI Studioで無料でガンガン投げられていた時期がチートだっただけでした。 解説 Gemini 2.5 Proはとても賢いです。1M contextに対応していてかつ、needle in heystack テストで

Roo Codeのプロンプト組み立てロジックのコードリーディング調査を題材に、Claude 3.7-SonnetとGemini 2.5 ProとGPT-4.1で比較してみました。 Roo Codeを使っています。 このプロジェクトにおける、会話二回目のときに、LLM実際に投げられるデータはどんな形式になっている？Claude を事例に。 制約条件: * 実際にメッセージを組み立てるのに必要な全部のソースコードを確認しろ * 厳密に再現しろ * system prompt は除外しろ * JSON形式で出力しろ * 環境情報などはダミーで良い 題材: 「README.mdを要約して」 { "messages": [ { "role": "system", "content": "You are Roo, an experienced technical leader who is inqui

最近Roo Codeで使われているBoomerang Modeに関する、筆者の感想と現時点での使いこなし術についての記事です。 Boomerang Modeが何か サブタスクとは何か Boomerang Modeでの筆者の使いこなしプロンプト などを書いています。 Boomerang Modeとサブタスク Cline/Roo Codeには元々サブタスクという機能があります。ただし、通常範囲で使ってる限りではサブタスクが起動されることはありません。 Roo Codeは、ClineやCursorよりも、きめ細かくモードを定義可能です。Plan/Act だけではなく標準で、Architect/Code/Ask/Debugなどのモードを持っています。モードごとに、ファイル操作などの権限が変わります。 さらに、Roo Codeは .roomodes というファイルを使って、ワークスペース単位でモード

コーディングエージェント（ClineやCursorなど）を使っている人は、うまくいくときは少ないプロンプトでさくっとやってくれるのに、あるタスクではそうじゃないという経験をしたことがあると思います。 「高速目grep」は、コーディングエージェントの途中経過を目で確認して、「待て、それはあかん！」って止めた上で、指示を出したり、作業をなかったことにしたりするものです。 これが必要になるケースを分類すると、筆者の理解では次の通りです： 使うべきじゃないテクニックを使ってしまう 使うべきじゃないライブラリなどを使ってしまう 場当たりなことをやらかす 設計ミスをやらかす 現行世代のLLMは、コーディングエージェントでは圧倒的にノウハウが確立された3.5/3.7-sonnetや、世界最高峰の頭脳であるGemini 2.5 Proですら、こういう「やらかし」は日常茶飯事です。 やらかしに対処するために

アイコンが変わったerukitiです。最近はやりのgpt-4o image generationを使って、顔だけだったアイコンに全身が追加されました。2023年4月10日に初めてのLLMプロダクトの開発キックオフからもうすぐで二年です。rat yearなこの業界なんで、変化がめまぐるしすぎますね。 今回は、真に高速なAIコーディングのメソッドを確立するために、中規模くらいのコードをコーディングエージェントのみに書かせる実験をしています。コーディングエージェントはCline派生であるRoo Code（以後Rooと呼ぶ）を使っています。 ※完全に個人研究としてやっているため、会社のリソースは使っていません。 作っているものはコーディングエージェントのコアライブラリ + おまけのCLI 規模としては136ファイル・26410行（一時期30000行弱までいった） なぜコーディングエージェントを使っ

これは 【Zenn 初開催】AI エージェント開発に挑戦！初心者歓迎ハッカソン の参加記事です。AI関連の会社に勤めている筆者ですが、完全に個人の資源と時間で、一人で参加したものです。 Tascario概要 Tascarioは、技術文書やLLMとの会話のような、日々大量に生じるインプットをGemini-2.0-Flashを使っていい感じに分析して、人間の思考負荷を減らして助けるためのプロダクトです。 記事を取り込んで分析して、今読むべきか？得られる知見は何か？その記事から得られる洞察、取るべきアクションなどが分析されます 自然な言葉で取り込んだ記事を検索して、今ほしい情報を取り出すことができます でAGPLですが、ソースコードを公開しています。正直、ぐちゃぐちゃなコードなので、こういうのもあるんだ、くらいの参考にしかならないと思いますが、見てみてください。 対象ユーザー 日々の情報に溺れて

この記事はLLMをAPIで使うこと前提の記事です。 AI エージェント開発ハッカソン参加記事：Gemini 2.0 Flash で技術文書分析ツール「Tascario」を作ってみたの、技術的補足記事です。 APIでLLMを使っている皆さん gemini-2.0-flash を使っていますか？APIで使う限り、かなり性能が高く、コスパも良すぎて、APIならこれ一択で良いのでは？とすら思い始めています。

この記事は、技術同人誌/技術を取り巻く様々な執筆 - Qiita Advent Calendar 2024 - Qiitaの16日目です。 ChatGPTやClaudeなど（以下、LLMと呼ぶ）を使って技術文章を書くというのは、まだまだ発展途上の分野です。「LLMに丸投げすれば楽ができる」という単純な話ではありませんし、逆にLLMを全く使わないのももったいないです。この記事では、筆者が実際に技術同人誌を執筆する中で得た、LLMを活用した効率的な文章作成の具体的なノウハウを解説します。 この記事を読むことで、以下のような知識が得られます。 LLMを活用した効果的な校正・推敲の方法 著者の文体や個性を保ちながらLLMを活用するテクニック 原稿の質を高めつつ執筆時間を短縮するためのプロンプト設計 各種LLMモデルの特性を活かした使い分け方 対象読者は、ブログや技術同人誌を書いている、あるいはこれ

この記事はLLM・LLM活用 - Qiita Advent Calendar 2024 - Qiita の12日目で、プロンプトジェネレータについてのものです。 いまはもう12/13かもしれませんが、僕の心はまだ2024/12/12なのです。 プロンプトジェネレータとは、LLMへの指示（プロンプト）を動的に生成するためのツールです。 多くの場合、プロンプトは静的なテキストとして書かれますが、それには大きな課題があります。LLMの進化が速く、昨日有効だったプロンプトが今日は機能しないかもしれません。あるいは、より良い方法が発見される可能性もあります。そのたびにプロンプトを書き換えていくのは、まさに技術的負債の山を築いているようなものです。 本記事では、TRPGのシナリオ生成という具体例を通じて、プロンプトジェネレータの実装方法とその利点を解説します。 プロンプトジェネレータについて、この記事

あなたはTypeScriptシミュレータです。step by stepでコードをシミュレートし、実行結果を出力してください。 ```ts const hoge = "hoge"; const hello = (...args: string[]) => `hello, ${args.join(" ")}`; hello(hoge, "world"); ``` これだけのシンプルなプロンプトで、解説を交えて逐次実行した結果を出力してくれます。もちろんTypeScriptだけではなくて他の多くの言語も処理できます。 GPTがプログラムの処理系になれるし、自然言語の操作もめちゃくちゃ上手、ということで、このテクニックは、いろいろと応用が効くはずです。もう少ししたらスクリプト言語ガシガシ入れたプロンプトが流行りそう。

プロンプトエンジニアリングの記事です。 ChatGPTなどGPT-3.5系である程度安定して、加工しやすい出力を得るためのノウハウができたので書きました。土日に別の実験をしていて副産物的に得られたものです。 サンプルコードはTypeScriptですが、プログラミング言語に依存した話ではありません。簡単な正規表現による文字列置換のサンプルです。 出力を得られると何が嬉しいのか？ 自然言語を自然言語で加工して、キーと値のペアを取得する、JSONを取得するなどすることができるようになるため、テキストを処理できる汎用ミドルウェアとしてLLMを使えるようになります。おそらくLLMを本格的にソフトウェアに組み込んでいく上で、基礎テクニックとなるでしょう。 異なる複数のプロンプトをつなぐときにも大切なテクニックです。 基本的な考え方 GPT-3.5系ではフォーマットを提示するとそのフォーマットに沿ったテ

最近は、生成AI関連のニュースが非常に注目されていますね。連日のように画像生成または文章生成に関するニュースがあり、とても大きなニュースが毎週出てくるほどです。そして、2023/3/2（本国では3/1）の朝に筆者が目を覚ますと、タイムラインがChatGPT APIリリースの話題であふれていました。 この記事は、TypeScriptでChatGPT APIこと Chat completions API を使ってみるというものです。 ChatGPTを使うためには、OpenAIのアカウントが必要です。アカウントを持っている人は、$18のクレジットが付与されているため、その範囲内であれば3か月間は無料で利用できます。この記事を参考にして、ぜひAPIを実際に操作してみてください。APIは非常にシンプルでアクセスしやすいものになっています。世界の変革を自分自身で体験してみたい方は、まず手を動かすところ

ChatGPTには、ニュースにならない日がないくらいの話題性がありますが、そんなChatGPTも決して遠くの技術ではありません。完全に同じものは無理でも、それに近いクローンを作ることはさほど難しくありません。 この記事はTypeScriptでGPT-3.5を使ってChatGPTクローンを作る第二弾で、今回はVite+React+TypeScript+Tailwind CSSでChatGPTクローンをウェブアプリとして作ってみます。 第一弾: TypeScriptでGPT-3.5を使ってChatGPTクローンを作る1 - GPTで検索エージェント 第一弾の記事では大規模言語モデル（以下LLM）であるGPTの使い方や、DenoでOpenAI GPT APIとGoogle Custom Searchを使って時事ネタも対応できる検索エージェントを作りました。今回の記事は、よいウェブフロントエンド開

OpenAI が提供している ChatGPT は非常に面白いですね。今年以後、GPTやChatGPT周りがさらに流行ると思います。 この記事は、TypeScriptでChatGPTクローンを作る第一弾です。長くなりすぎるため、この記事では、GPTを使った検索エージェントを実行するまでを取り上げます。 検索エージェントは「ぼっち・ざ・ろっくの作者は？」と尋ねたら検索エンジンとGPTを使って「はまじあき」という結果を生成できる技術です。 またこの記事や、続く記事でLangChainのプロンプトをあれこれ読み解いていこうと考えています。 筆者は機械学習の初心者であるため、間違ったことが書かれている可能性があります。間違いがあった場合は、ぜひご指摘いただけると幸いです。 なお、この記事では添削にChatGPTおよびGPT-3.5を使っています[1]。 どうやってTypeScriptでChatGPT

フロントエンドやバックエンドを Node.js でチーム開発をしていると package.json が更新されているのに、気づかずそのまま実行してエラーが出るみたいな現象が生じがちです。 コミュニケーションその他でカバーすることも可能ですが、我々プログラマたるもの、全て自動でやるべきです。そこで、Git の pre commit hook に使われることの多い husky を使って、更新を検知してフック処理を実行してみましょう。 husky https://www.npmjs.com/package/husky Husky は package.json 上で、Git フックをいい感じに扱える便利なパッケージです。よく使われるパターンは lint-staged というパッケージと組み合わせて、コミット時に eslint や prettier あるいは TypeScript の型チェックを走ら

OpenAPI によって記述された API 定義ファイルをもとに、TypeScript の型や API クライアントを自動生成するというのは一般的に多用されているはずですが、意外に資料が全く見つからなかったのでまとめました。 ぶっちゃけクッソメンドいし、文化圏的にアレなところ多いので、使わなくて済むなら使わないほうがいいです。 OpenAPI/swagger OpenAPI は、もともと API 仕様を JSON/YAML の類で記述して、バックエンドとフロントエンドで共有しようという技術は山程あってその中の一つに過ぎなかった Swagger が発展してデファクトスタンダードになった仕様です。 OpenAPI Specification ソースコード生成 OpenAPI からのソースコード生成のデファクトスタンダードは OpenAPI generator です。 ただし、Java で書かれ

Node.js で子プロセスを生み出す場合、Node.js というコマンドラインで起動するツールである都合上、たいていの場合は、Ctrl+C で止めることが多いはずですが、そうじゃない場合に子プロセスが生き残るよね、どうやって殺す？という話です。 たとえば const childProcess = require('child_process') childProcess.exec('sleep 10000')

ソフトウェアエンジニアリング界隈の言葉はとても曖昧な言葉に満ち溢れています。「自走」という言葉もそうです。でも、そういう曖昧な言葉の方が使い勝手が良いため、たとえば、ツイッターランドにはそういう曖昧な言葉がバズりまくったり、日々流れてきたりします。そうじゃなくても、「うちの職場のエンジニアには自走力が求められるんだよね」とか「転職するためには自走できる力が大切だ」みたいな言い方、度々聞いたり、むしろ話したりしていませんか？ この記事では「自走できるエンジニア」について自分なりの考えをまとめてみたいと思います。もちろんこれはあまたある解釈の中でも、僕が解釈したものに過ぎません。そういう意味ではさらに「自走」という単語を持ち出して世に混乱を投げつけるだけかもしれません。僕のただのポジショントークかもしれません。 それでよければ、「自分は自走できているのだろうか？」「自分は、うまく部下や同僚を自

言語関連 ECMAScriptの最新版を使うのは完全にありだと思う。ここに技術的難易度はあまりなく、メンバーへのフォローもしやすい。stage-x の技術とかもそれなりに問題なく使える。むしろここを変に以前のバージョンに固定すると、メンバーのアンガーがたまりすぎるので気をつけよう。 TypeScript TypeScriptは絶対に導入すべきだけど、静的型付け言語を未経験の人には少しつらいかもしれない。ここのフォローをどうやっていくかは課題。なにかこの層の人たち向けの TypeScrpit 教材を渇望する。型に関する営みにピンと来ない人が多いので、型があると何が嬉しいかを最初に教え込むことが大切そう。また、この層の人たちにはVSCodeの導入と、プラグインなどの設定をオンボーディングすることが絶対に必須。 Linter, formatter ひとまず eslint, prettier は絶

E2E テスト・結合テストによく使われる Cypress ですが、どういうふうにやれば記述しやすくなるのか？たとえば、QA の人が、自分たちの作業を楽にするために簡単に記述できれば理想形です。 そこで今回は、Cypress で、要素を指定するためにアクセシビリティ用のデータを使うというのを試してみました。 もともとは Puppeteer と ARIA Handler | Medium という記事を読んで以来、ずっと頭の片隅に引っかかっていたものです。 アクセシビリティ用のデータを使うことで、ユビキタス言語を使って、要素を選択できるというのはプロジェクトにとってはとても有益です。 今回は aria-label を指定するというやり方にしました。 aria-label aria-label 属性の使用 - アクセシビリティ | MDN aria-label 属性は、現在の要素にラベル付けする文

とある大規模開発プロジェクトの中で WebView 用のフロントエンドシステム開発を立ち上げて2ヶ月経ちました。Android, iOS専任のエンジニアがいないため、外部協力者の指導のもと、モバイルアプリの画面を WebView で作るためです。 ある程度その営みについて見えてきたものがあるので記事にまとめることにしました。 プロジェクト参加人数は30名以上 プロジェクト自体は4ヶ月前から動いてる このプロジェクトへのフロントエンドチームの参加は1月から 現在 WebView とモバイル・バックエンドなどの結合試験をはじめている 背景 去年12月いまの会社にテックリードとして入社し、前述とは別のプロジェクトでフロントエンドチーム立ち上げを行っていました。同タイミングで、いまの会社に誘ってくれた飲み仲間もテックリード・チームリーダーとして入社しています。フロントエンドチームはこの2名がプロパ

Webのフォームは、いつでもベストプラクティスを悩むものの一つです。React を使うとして完全に自作でやるのか？それともフォームライブラリを使うか？フォームライブラリならどれを使うか？ 今の時代 Formik を選ぶ理由はありませんが、React Hook Form と React Final Form のどちらを使うかはとても悩ましいです。 React Hook Form は利用経験者・採用実績が多い、速度が速いなど様々な利点はありますが、React 哲学に反する作りなどクセの強さが難点です。あと良くも悪くも利用シーンが豊富でドキュメントも豊富で迷子になりがちです。 React Final Form は Final Form の React wrapper です。個人的にはこちら React 的使いやすさに反すると感じてること、React Final Form として見たときにドキュメ

React でユニットテストをするときのベストプラクティスはいつも悩むのですが、とりあえず 2021 年 2 月時点では、こうかなーというのをまとめてみます。 まずテストランナーは jest で確定です。ここで悩む要素はまずありません。 では、React のテストをどうやるか？です。 公式の react-dom/test-utils を使う 公式の react-test-renderer を使う @testing-library/react を使う 選択肢としてはこの三種類が有名なところでしょう。 公式という響きはとても魅力的ですが、実は公式ドキュメントから「ボイラープレートを減らすため、エンドユーザが使うのと同じ形でコンポーネントを使ってテストが記述できるように設計されている、React Testing Library の利用をお勧めします。」という形で、@testing-library

仕事で Windows マシンを触っているので、すごく久々に Windows で Node.js 環境を構築しました。 WSL2 を使える前提であれば、WSL2 + anyenv + nodenv が、現時点での選択肢としては最善かなという気がしています。 ただ、様々な事情により Windows Native の Node.js を構築しなければいけない状態で、七転八倒した僕の結論としては、scoop + nvm がベターチョイスということになりました。 Chocolatey ではなく scoop を使う Nodist ではなく nvm を使う この 2 点だけ覚えておけば大丈夫です。 これ以後の記事はおまけです。 パッケージ管理ツールに Chocolatey ではなく scoop を使う Windows のパッケージ管理の定番は、Chocolateyです。ところが Chocolatey

React Server Components に感じたフロントエンドの消失という記事に端を発する一連の議論だが、実際この記事で書かれていることはそうだろうなと思う。話の流れとして誤ってる部分はないと思うし同意する。 この記事ではフロントエンドエンジニアとして、この件についての僕の見解を書く。もちろんフロントエンド（とは？）の総意ではない。 元記事と重複する部分多いが、そこは同じ問題を取り扱う以上避けて通れないため、ご容赦いただきたい。 同じ領域を取り扱ってる以上、開発戦争は激しくなる 様々な理由によりユニバーサルが求められている ※この記事でいう「戦争」とは、お互いの領域を食い合う開発が、活発化することを「戦争」と称しているだけです。それ以上の意図は全くございません 領域がかぶっている 最近のフロントエンド系ユニバーサルエコシステムは、たしかに PHP や Rails の領分を侵そうとし

去年末に Facebook の人達が出した React Server Components というものが、React 界隈に激震を及ぼしていますが、速報以外でこの技術について言及している国内のブログが見当たらないため、この記事で解説してみます。間違いや分かりづらい部分があればぜひツッコミをお願いします。 React Server Components は、ただのサーバーサイドレンダリングではありません。クライアントサイドレンダリング（SPA）とサーバーサイドレンダリングを、ギアを切り替えずにいいとこ取りする仕組みです。これまでに存在した様々な技術よりも踏み込んで、フロントエンドとバックエンドの境目を曖昧にしてしまうユニバーサルな技術です。 勝手な造語としていうなら「コンポーネント指向ユニバーサルウェブ開発」とでも呼ぶべきものでしょう。 そして、これはただのユニバーサルなだけの仕組みではあり