日々のつぶやき

並び順順序

2026年10月4日

レビューAIを作って開発効率を上げてみた

こんにちは。今日はAgent開発のお話です。実装する際にAgentは普段利用していると思いますが、実装した内容が本当に正しいかを検証する必要がありますよね。 AIDDで大量のPRを全てレビューするのはリソース的に難しいので、レビューもAIに任せてしまおうというのがモチベーションです。実装だけではなく、レビューもしてーっていうと実装内容を肯定した評価になってしまうため、別のAgentを利用することでこれを回避するようにしました。構成はこんな感じです。(2026-10-04現在) 実装AI: Codex GPT-6 Luna (Plus契約) レビューAI: Gemini 3.8 Flash (API経由) なんで今の時代にGemini??って思うかもしれないですが、価格とレスポンス速度が他のAgentに比べていい感じなので選定しました。また、従量課金ではなく前もって購入できるのも魅力でした。なら、6Lunaとか5.6Lunaでいいのでは?という意見があると思いますが、おっしゃる通りです。 5.6Lunaが出る前にGeminiに課金をしてしまったんですよね。進化が速すぎます。とはいえGemini3.8flashも世間が言うほど悪くはないと思っています。実装が微妙なときはちゃんとレビューしてくれるので全然アリです。お陰でほぼレビューすることなくマージ出来て、開発効率が爆上がりしました。 1日Plusを使い込んでも300円程度なのでお財布にも優しいです。是非みなさんもレビューAIを導入してみましょう。それっぽい感じになって楽しいですよ。 ### さいごに最近CIとかレビュー機構とか色々組み込みすぎて、Plusだとトークンが足りなくなってきました。(AstraとかSol使って実装したいです。) Proにしたいところですが、お金なくなっちゃうので一旦我慢します。誰か私に仕事ください。

2026年9月29日

今日のリリースした機能をまとめてみた

疲れ様です。今日は有給を消化しないといけなかったので、個人開発にフルコミットしました。 codexのリセットチケットが3つあったので全部使いました。 Plusだとせいぜい1.5時間くらいしかもたないので、そろそろProにしたいところです。でも使う日と使わない日の差が大きすぎるのが悩みどころですね。月にまとめてトークンもらえるようにしてほしいです。さて、今日のリリース内容です。 | PJ | Close PR | Close Issue | |---|---:|---:| | 本サイトの開発 | 35 | 36 | | 開発基盤 | 19 | 19 | | 個人開発 | 3 | 4 | | **合計** | **57** | **59** | 具体的に対応したこと: - Googleサーチコーンソール・アナリティクスの登録・計測開始 - サブドメイン作成 - エラー処理・管理画面・UI・Analytics・Staging環境を広範囲に改善 - HTTP 429周りの扱いをAPI / Svelte双方で整理 - DB migrationの安全性をCIと共通Actionで強化 - Gemini Reviewerを中心としたAI開発フローを大幅に強化 - PR Quality Gate、Agent状態管理、レビュー証跡、E2E基盤の整備こうしてみるとかなりやりましたね。昔なら1ヶ月あっても出来た気がしないです。これ以外にもちょっとしたUIの調整や不具合対応をやりました。稼働は7時間くらいでした。恐ろしいです。まだまだ残タスクが大量に出てきたので、暇なときに解消していきたいです。さいごに最近は慣れてきましたが、キャパを超えた作業量なので体に絶対に良くないですよね。でもトークンがもったいないのでやっちゃうんですよね。もうAIがないと開発ができません。夕方くらいに昼寝すればよかったと後悔しましたが、その楽しみは土日にとっときます。それでは。

2026年9月27日

このサイトのissue numberが500を超えました

こんばんは土日はまったり開発ライフを味わうことができました。昼まで寝てダラダラ作業できるの気持ちが良いです。今日は個人ブログの開発をしてたんですが、気づいたらissue番号が520になってました。AI駆動で開発すると爆速で気分がいいです。多分今日だけでprを40個くらいマージした気がします。個人的にpasskeyをサイトに導入できたのが嬉しいです。仕組みがよく分かってなかったですがなんとなく理解することができました。認証方法が複数あると管理が煩雑になるのでうまく出来るようになりたいです。あとはエラーログやユーザーのコメントをリアルタイムで追えるような仕組みを作りました。本当はSlackに通知させたいですが、お金がかかるのでいつもdiscordです。discordはまじで神。あとはQiitaの投稿データを自動で同期する仕組みを作ったり全体のUI/UXを調整したりしました。特にこの入力するフォームが地味に大変でした。AIが実装したものだとかなり入力しづらくてストレスでした。なのでnotionやnoteのような広く使われているプラットフォームを参考にさせるようにしたらうまく行きました。UXはまだまだ弱いなぁって思いますね。スキル化させたいところです。色々進捗があって悪くない土日でした。明日からも程々に頑張りたいです。本も読まなくては、、

2026年9月26日

技術的負債の解消ってどこまでやればいいの?

こんばんは。もう深夜ですね。シルバーウィークもあって休みが多すぎるせいか、一日中開発をしてました。時間経つの早すぎる。まだまだやりたいことはありますが、明日に回したいと思います。さて、今日は事業会社あるある?の課題について話したいと思います。かなり長文になるので暇な時に見てください👀 エンジニアは時として、ソフトウェアの品質を保つために利用していない機能や現在利用している機能の品質向上を取り組む行為をします。現在僕はこの対応をしており、色々疑問や課題を持ったので書き連ねることにしました。今僕が開発しているサービスが10年くらい続いていて、相当な技術負債が溜まっています。規模としては1000個くらいのAPIがあるようなWebサイトです。利用していないAPIがかなりあるのと、既存のAPIをよりセキュアにする対応が求められています。消すだけなら簡単だろーって思うかもしれないですが、Railsの強みでもあるメタプログラミングによってかなりしんどいです。あとRubyはコードジャンプができないので、利用しているかどうかが非常に分かりにくいです。ポリモーフィック関連とかもあって辛い。。本当に使っていないのかを調べるために、DBの履歴やGitの履歴を参照して問題なさそうかを1つ1つ検証しています。また事業部の担当の方にも本当にいらない機能かどうかを一応聞く必要があるため時間がかかります。(ニッチな機能だと事業部の方もしらないことが結構あります) セキュリティ対応については、APIによって対応が1つ1つ異なるため、これも相当きついです。 4年ほど前に大規模な仕様変更があり、この残骸もかなり残っています。不具合対応だけやるとセキュリティに穴が生まれてしまうため、同時に対応しなければいけなかったり。1つのAPIを直すのに影響範囲が大きくなってしまうことも度々あります。これらの対応はやればやるほどソフトウェアの品質が向上するので素晴らしいことなんですけど、事業部側にとっては1円も価値が生まれない行為なんですよね。マイナスを0にする行為でしかないので。特に私の会社はエンジニアが全然いないので、新規開発が疎かになると全体に影響が出ます。もちろん理解はしてくれていますが、数カ月この対応だけをやるというのは現実的ではありません。機能開発と並行してやる必要があります。でも、できる限り技術的負債を減らした状態で新規機能の開発を行いたいなぁとモヤモヤした気持ちになります。なので、2~3週間くらいかけて、よく利用する500個くらいのAPIのセキュリティ対応を一旦最初にやることにしました。具体的には、認可の共通基盤の作成と既存の脆弱性やパフォーマンス、不具合の対応を集中して行いました。残りのAPIの対応を現在進行系でやっていますが、機能開発と並行してやっています。何もやっていないやつと思われるのは悲しいのと、できる限り事業部の方の期待に応えたいのもあります。あとは、よく利用する機能の対応が終わったのなら良いじゃんーってなりそうですが、ここで今悩んでいます。また2-3週間開発リソースを割いて対応をする必要があるのか?と。全部の穴を埋める方が遥かに難しく、ちゃんとやるなら2ヶ月くらいほしいところです。でもセキュリティってめっちゃ重要ですし、使っていない機能を誤って使っちゃってしまってインシデント発生☠️。みたいなことも起こり得ます(7月末に経験アリ) お金と開発リソースに余裕があれば良いんですが、SaaSとかのIT会社と違ってソフトウェア製品で商売をしていない会社はここが辛いところです。文句を言ってもしょうがないので、自身の可処分時間をできるだけ増やすことに決めました。4つほど案があります。 1. デプロイ時間がボトルネックだったので、短縮する機能の開発をしました。まだリリースしていませんが半分くらいの時間になる予定です。タノシミ 2. CIテストの時間短縮です。1つ目と同じですが、待ってる時間が結構あるのでうまい具合に調整したいです。 3. 事業部側とのコミュニケーションコストがかなりかかっていたので、AIチャットボットを利用してもらうことで原因調査の時間が減った気がします。 4. 最終奥義の残業です。この時間は思い切って品質向上に振り切ってやっています。上でカッコいいことを言いましたが、圧倒的に効果がありますという具合で最近は1つずつのAPIをチマチマ対応しています。でも、やってよかったなぁって思ったのは、Railsのコードを理解するのにとても良い機会でした。色々な記法で書いてくれてありがとう。うざいので1つに統一しているよ。あと、全てのAPIを見るので、ドメイン知識がかなり身につきました。これはありがたい。引き続き4番を意識してゴリゴリ開発を進めていきます。完了するときを夢見てます。 [さいごに] 今リファクタしてるRailsのシステムを来年か再来年にgoにリプレイスする予定なんすよね。おい、こんな作業やるなよ!!って思うかもしれないですが、スパゲッティーをほどかないとリプレイスなんてできないので、麺をほぐしています。あとは脆弱性という爆弾処理をする必要があるのでやるしかないです。っていう、ちょっとやるせない気持ちになりながら普段作業しています。とはいえいち早くgoにしたいので引き続きガンバリマス。みなさんの開発内容とか聞きたいので是非教えてください。特に同じような事やっている人いたら教えてください。とても気になります。

2026年9月23日

バージョンが古いせいで障害を起こしてしまった件

こんにちは。今日でシルバーウィーク最終日ですね。雨がやばすぎて外にあんまり出れなかったです。でもドラマやアニメをたくさん見れたので良いリフレッシュになりました。かなりだらけてしまいましたが。さて、今日は障害を起こしてしまった話をしたいと思います。業務でrailsを触っていますがこちらのバージョンがかなり古いアプリです。そこで最近起きる問題がAIが割と新しい記法を使ってコーディングをしてくることです。古いバージョンのアプリについてはこれがかなりきついです。一見正しそうに見えますが、実行してみるとエラーになる。調べてもそれっぽいので原因を調べると最近のバージョンで導入されたとのこと。実行時にエラーが出るならまだいいですが、本番環境だけ起きるエラーにもこのまえ遭遇しました。(これで障害を起こしてしまいました)。内部実装だけ変化するパターンです。昔は非効率な処理をしていたため、そのまま書くとエラーが起きるが、最近のバージョンで修正が入り、問題なく動くようになったみたいな状況です。当然LLMはその修正を知っているため、その手法でいいじゃんって思って書くとエラーが起きる。開発者もlocalやstaging環境で動作確認をしますが、データ量が違うせいで普通にpassしてしまい、リリース後に障害が起きてしまいました。悲しかったですし反省しました。これを受けて、障害が起きた箇所の内部構造の調査をかなり行いました。 AIが見えるように同様の処理をしないように注意することと、チーム内での共有を行いました。でもAIも人間も当然新しい文献を参照するので、別の障害を防ぐことが出来なさそうです。 AI駆動で開発するためには: 1.本番環境とSTG環境をできる限り同じにするこれは以前までもあたりまえですよね。時間が立つとデータ量や内容に乖離が生まれてしまいます。開発に追われていると中々基盤の調整をする時間を割けないですが、とても重要なことなのでできるだけ同じ状態に維持したいです。 2. 最新バージョンを維持するこれも当たり前ですよね。パフォーマンス向上や脆弱性を防ぐためにも上げたほうが確実に良いです。でも古いバージョンだともう上げられなかったり、ライブラリやフレームワークとの互換性がうまくあわなかったり等の問題が生じます。破壊的更新によりコードの記法が変わりエラーが起きることもあると思います。コストが非常にあがるので放置せずにこまめに上げるようにしたいです。 3. AIに現在のバージョンのdocumentを読み込ませる 1も2も出来ない場合ってありますよね。その場合はAIに頼りましょう。その当時のドキュメントやコードを食わせて危ないところを覚えさせるのが良いでしょう。今回障害を起こしてしまった内容をAGENETS.mdに記載するようにしました。また、まだ私はやっていませんが、利用しているバージョンから最新のバージョンの修正した箇所やこれから修正するべき内容を参照させてみたいです。以上1~3を心がけて開発を進めるようにしたいです。もう障害は起こしたくないです。追記: エンプラのシステムってAI導入でこのような障害めっちゃ起きそうですが、どうやって回避しているんでしょうか? Javaとかバージョンの違いですごい起きそう。是非共有してくださいmm それでは。

2026年9月18日

久しぶりの長期休みで何するかを決める

こんばんは今週ももう終わり、明日からシルバーウィークです。旅行に行く人をチラチラ見かけます。羨ましい。今月中に有休を取らないといけないので、木曜日にとります。予定ないのに6連休。適当に過ごしていると、あっという間に過ぎちゃうので予定を立ててみることにしました。計画通りにいくとも思ってないですが、形から。まずはやることを列挙します。 - 飲み会 - レンタカー借りてどっか行く - 応用情報キャッチアップ - rails, rubyの本を読む - railsコントリビュート - デプロイ時間短縮意外にやりたいこと多いんですよね。結局何もしなかったってことだけは避けたい。次にいつやるか決めます。金-日: 大学時代の友人と飲み🍺&レンタカー借りてどっか行く。混みそうなので人いない所に行けたらなと思ってます。可能なら泊まりたい。これから飲むので作戦会議します。日: rubyとrailsの本読む。100ページ読みたいな。月: デプロイ時間短縮。まじで業務効率落ちてるので色々実験してみます。解決方法は分かってるけど、どう実装するか。。火: rails, rubyの本を読む。railsにコントリビュートしてみる。業務でrailsを書いてるので力をつけたいです。ネタも出来たのでコントリビュートチャレンジしてみます。水: 応用情報？　やる気出ないですよね。勉強するつもりはあまりないですが、まずは敵を知ります。木: こんだけ長いとだらけそうですね。バッファのためにこの日はだらける日とします。こんな感じで行きます。ほんとうは海外旅行いきたいです。写真くださいそれでは。

2026年9月14日

改めて横浜観光してみた

こんにちは今日は週末に横浜の観光スポットを回ったのでだらだらと話します。以前まで横浜に住んでいたものの、観光地にちゃんと行ったことがなかったので行ってみました。行程はこんな感じです中華街→山下公園→みなとみらい→横浜まず中華街で肉まんを食べ歩きをしたあと、お店に入りチャーハンを食べました。角ハイがかなり濃かったです。日曜だったので人がかなり多かったです。でも海外の人が全然いなかったです。確かに日本で中華街いく必要ないか。タピオカ飲もうか悩みましたが、腹パンだったので、諦めて山下公園へ。　花火大会とかでしか行ったことがなかったので、人がやばいイメージでしたが、土日でも全然ゆっくり過ごせました。今度レジャーシート持って行ってゆっくりしたい。そのあとみなとみらいまで散歩してクイーンズスクエアのスタバで休憩。ダークモカチップフラペチーノにハマっています。可能ならホイップ抜きにしたいですが、カスタム怖くてできないです。休憩後に横浜駅に向かってもんじゃを食べて締めました。もんじゃって下町の味みたいなイメージですが、値段普通に高いですよね。お好み焼きより高いの謎です。下手な観光地を巡りましたが、意外に満足度高かったです。次は元町とか三溪園に行こうかなと思っています。おすすめスポットあったら教えてくださいそれでは

2026年9月5日

大規模なリファクタリングに着手

こんにちは、今週もあっという間に終わってしまいました。週3リモートだったので特にあっという間でした。今月はカンファレンスへの参加を減らして、開発時間を多く取る予定です。さて、今日はリファクタリングについてです。私が今着手しているプロジェクトは10年くらい続いてるわりと長いシステムです。railsとreactを利用しています。 2,3年前くらいに大規模な仕様変更がおこり、以前のコードを使いながら今現在まで運用を行ってきました。今回セキュリティのタスクを任され、既存のコードを使いながら対応するのがかなり難しく、リファクタリングを試みました。難しい理由として、railsが名前解決を自動で行ってしまい、想定外のコードを読み込んでしまうといった課題があります。実行やテストするまで分からないのがとても怖いです。また、イケてないコードもあるのでその対応も同時並行で行っています。ディレクトリ構造を変更しているため、差分が差分が多くかなり大変です。数百個のapiとviewを対応して行く必要があり気が遠いです。また、その間は事業に何も貢献できていないので、そこのモヤモヤ感もあります。どうせなら開発でお金を生み出したい。。ただ，一方で10年くらい続いてた負の遺産をここで大きく解消できる大きなメリットもあります。このタスク終わったらめっちゃコード書きやすくなりそうです。それをモチベに頑張ります。 p.s. なんでこんなに大変なんだろう。コントローラが分厚いせいなのかな。でもモデル層にロールが混在したコードを書きたくないです。使うべきでないロールが操作しちゃう問題がでてきそう。本当はrailsからgoに移行したいです。でもそんなことはできないので、rubyとrailsの本を買ってキホンを学びます。5ヶ月くらい触っててちょっとだけ好きになってきました。

2026年8月30日

個人開発の開発効率の最大化させる方法

こんばんは。今週末は超暇でお昼寝とパソコン三昧でした。最高です。9月はこういう時間をたくさんとりたい。(外にも出たいですが...) さて、今日は開発効率についてです。会社員をやりながら個人開発をするのはかなり大変です。限られた時間で機能開発やバグの修正を効率的に行う方法を最近作っているので紹介出来たらなと思っています。私が考える最終目標はこの2つです。現時点ではこの目標に対して10%くらいの成果ですが、日々これを目標として開発をしています。 [目標] - 新機能の案が浮かんだら、自動でリリースされる - バグや不具合を自動的に検知して自動で解消するこれを実現するために私が行っていることを紹介したいと思います。 1. Codex or Claude Codeの月額課金はい。これはマストですね。Agent開発をしないと始まりません。自分で書くコードを0にすることを意識しましょう。私はtoken量が有利という点でcodexを課金しています。(2026年8月)本当はKimi等の中国系のAIも触りたいですが、クレカとかが怖いのでちょっと触れていないです。 2. 共通基盤の作成 Agent開発の肝はこれに尽きると思います。作成されたコードがイマイチだったり、 AIが完成したと言っても全然出来ていなかったり、色々な課題が出ると思います。ここでAIのせいにするのはナンセンスです。全て使い手が悪いという謙虚な気持ちで開発に取り組みましょう。私が具体的にやっているのはコード規則、アーキテクチャ、開発フロー等を詳細に書くことです。いわゆるハーネスっていうやつですね。これをちゃんと構築しましょう。本当に性能が変わります。 3. AIの精度を上げ続ける仕組みづくり 2の共通基盤に紐づく話ですがこれも超大事です。例えばAというサービス開発をしていて、この前提知っておいてほしいんだけどなぁ。って思うときありますよね。そのときにチャットを毎回するのは時間があまりにも無駄です。一日100回くらいは全然あると思います。これだけで1時間くらい奪われます。そういった知識を保有してもらうようにしましょう。私は共通基盤用で1つのリポジトリを作成しており、このrepoのissueに自動で作成させるようなハーネスを作成しています。これをすることで共通基盤が賢くなり続けます。1~2年前のような情報量渡しすぎて精度が落ちるみたいなことは現時点で感じていないです。マジスゴイ。こういう小技をたくさん作ることで、自分の作業時間が減るので是非やっていきましょう。 [現時点での課題] 1. 共通基盤の作成に時間が奪われる。確かに生産量が10倍になる仕組みづくりを作ることは大事ですし、合理的だと思います。でも人間なのでこの間に個人開発のモチベがなくなちゃうんですよね。なので私は共通基盤を創りつつも開発をするようにしています。新しい機能とか考えるのはやっぱり大事です。作るものがなくなったら効率上がってもいみないですし。 2. エラーや不具合の対応がまだまだ未熟今月はアプリケーションコードは1行も書いていないので、開発効率はかなりあがっています。現在はエラーや不具合の対応にかなり追われています。AIチャットで対応しているので、エラーをどう効率よく捌くかを考えています。また、テストコードの生成もまだまだ貧弱ですね。仕様変更と既存のテストコードが競合することがよくあります。これをAIにどう判断してもらうか。。 3. マネタイズ開発速度が爆上がりした反面、コスト面がイマイチです。AIの月額料金やドメイン料金、クラウド費用 etc... トントンにすることを最大目標にしています。 [さいご] こういったハーネスってみんな個人で頑張って書いているんですかね? 開発手法は人によって違うのでまるまるコピペみたいなことができず微妙なんですよね。今後は世間のデファクトスタンダートに合わせるのが基本になってきそうですね。これからも動向を追っていきたいです。それでは

2026年8月23日

初めての障害対応

こんばんは。もう日曜の夜ですね。この週末はめちゃくちゃ寝ました。幸せですが、毎週やらないように気をつけたいです。さて、今週は障害対応を初めて行いました。月曜日に社員の方からslackで報告が来ました。通知を見た瞬間に冷や汗がでました。午前中でちょっと眠かったですが一瞬で目が覚めました。軽くDBを調査してみたしたがやはり報告通り。上司から対応いけますか?と言われたので「いけます!」と意気揚々と返しました。とは言ったものの何からすれば分からないのでログを見ることにしました。しかし有益なログを見つけることが出来ず、社員の方に詳細情報をヒアリングすることにしました。前から気になっていた処理の実行が行われていたため、その調査をすると何やら想定外の使い方をされていることに気づきました。その機能のログを見るとやはり怪しそう。ここまで4時間程かかりました。次に影響範囲はどれくらいなのかを調査することにしました。データやログの調査をすると影響範囲が小さいことがすぐにわかりました。しかし正確な範囲を捉えるために細かく調べると2~3時間かかりました。抜け漏れが合った場合に洒落にならないと思ったので結構時間がかかりました。次は同様の障害が起こらないように暫定的な処置を行いました。こちらは一瞬で対応が出来ました。次はデータ復旧です。こちらがかなりの曲者で、影響範囲が分かったものの正となるデータがなんなのかはログの前後関係を正確に整理しなければいけません。またログが豊富に残っていなかったため、相当慎重に整理しました。(かなりのストレスでした。) 整理が出来たら対応です。本番DBの操作は脂汗が出ます。この重圧に打ち勝ってSQLコマンドを実行して対応しました。最後に恒久対応です。こちらはもう日々の開発とやることは変わらないためいつも通りのマインドで取組むことが出来ました。結局3~4日この対応に奪われてしまいました。この経験から得られたこと: 1. 障害対応のフローを全て一人で対応出来たこと。対応フローを身を持って知ることが出来ました。実装以外のスキルが身についたので1つ強くなれました。 2. 障害対応は相当なストレスがかかることが分かりました。今回は私が実装したところではなかったのですが、もし自分の実装したところのせいだったらと思うと怖いです。対応最終日にはタバコがとても吸いたくなりました。吸ったことほぼないのに。 3. 最初から怪しい機能に対してチームでもっと議論しておくべきだった。障害対応で数日なくなってしまい、本来実装されるはずだった機能をリリース出来ませんでした。日々スピード感をもって開発をしているのでかなり痛かったです。障害が起きると時間と精神が削られるだけではなく、サービスの信頼も落ちてしまいます。なるべく起きないように日々チームで会話をするべきだなぁと思いました。それでも一定確率で起きてしまと思うので、そのときはできる限り速く対応が出来るようになりたいなぁと思いました。しばらくは障害対応したくないので安定稼働してくださいmm 平和が一番です。 p.s. google cloudで謎の費用が発生していました。原因は勉強用に使っていたcloud sqlのインスタンスがずっと起動していたことでした。ラーメン1杯食えたのでとても悲しいです。