こちらも書きました / AI時代の転職活動記録 chezo.uno/post/2026-04...

ここ最近は、友人が作る個人アプリやゲームなどからインスピレーションを享けることが特に増えた気がする。「こういうデザインがあるのか！」とか「こういう割り切りありなのか！」みたいなのがすごく刺激になる。巷で話題になるようなメジャーなプロダクトや商用プロダクトはもちろんどれも洗練されていて完成度も高いが、当然ながら多数の人を対象にしたものばかりなので「まあここはそりゃこう作るよね」みたいな納得感はたくさんあってもそこに驚きを見いだせることが少なくなった。そんな中で尖った個人アプリに触れるというのが自分にとって鮮烈な新しい体験となっている

ブログ書いた shiumachi.hatenablog.com/entry/everyo...

複数のデバイスから接続しつつ、きちんと同期をとってコンフリクトが発生しないようにしながら堅牢な構造にしてバックアップも確保する、みたいな自分用アプリを作ろうと思うと結局全体のアーキテクチャはAI任せにできず自分で設計するしかなくなってくるな

株式会社オープンコレクターを退職しました - 科学と非科学の迷宮 shiumachi.hatenablog.com/entry/goodby...

さらに見えてきた。機能やUIを削るのは多分人間にしかできない。AIは足すのはできても減らすのはかなり苦手

Claude Codeでゲームを作り続けて分かったが、何もしないタイミングを取るのがすごく難しい。いいゲームは「間」がうまいが、それはあまり言語化されておらず、また言語化するのが非常に難しい。

結局、作りたいものを絞ったりスコープを絞るというのはClaude Codeがあっても全然変わらない、というかむしろ下手にClaude Codeがあるおかげで中途半端にモノを作れてしまうので、より貴重なリソースである時間を浪費してしまいかねない

Vibe Codingで自分のためだけのゲームを作り続けていると、自分にとっての面白さとは何か？という問いだけに向き合い続けなければいけなくて、やってることは開発というよりむしろ座禅に近い

2025年初頭はまだ1年前のAIの知識、つまり2024年初頭の知識で語ってもギリギリ通じた気はするが、ここ最近は1年前の知識なんて話にならず、半年どころか下手すると3ヶ月前の知識ですら古いみたいな速度になりつつある気がする。1ヶ月前でもやや古いという感覚

自分専用のアプリを作る場合、多様なユーザーニーズを気にする必要がなくなる。例えば、自分にとって簡単な操作が一般の人にとっては面倒なこともあれば、多くの人にとってmustな機能が自分にとって煩わしいこともある。AIエージェント開発ならこういう自分だけの設計にすることが簡単になる

私を含めた友人達がAIエージェントを使って「自分だけのアプリ」を作って公開しているのを見ると、2000年代の個人ホームページブームの再来はある気がしてくる。AIエージェントでの開発は、大ヒット志向よりもむしろ自分専用あるいはスーパーニッチなこだわりアプリの方が夢があるのではと思う。

ドメイン知識が深いということは、「そのドメインについてAIが出力したときに、どれだけテストを思いつけるか」というところにつながる気がする。例えばコードに関するテストはいろいろと思いつけるが、法律や医療関連の出力に関するテストは私には思いつかない

AIを休まず使い続けるには長時間の思考に耐えられるスタミナが必要なので、AI時代のエンジニアの勝敗を分けるのは「よく寝てよく運動して健康的な生活を送ること」なんじゃないかという気がしてくる

Claude CodeでAskUserQuestionを活用したりplanモードを活用すると設計レベルも大体自動化できるようになってくるので、次は要件定義をどれだけ自動化するかだな。ふわっとした要件を高速かつ正確に要件定義できるようになればさらに開発速度を上げれる

問題検出の早期発見の原則から考えると、設計や要件定義のフェーズにOpusガンガン回して自己レビューさせまくる方が実装レビューに使うよりも多分トータルコストが減るんじゃないかと思ってる。この辺は全く未検証で、憶測レベルの仮説ではあるが

ゲームの中に入る系の創作だと開発者も知らない機能、キャラクター、アイテムが出てきたりして、こういうのはお話の世界だけで現実にはないと以前は思っていたが、いざ自分がAI任せでゲーム作らせてると知らないものが勝手にあれこれ作られてたりするので現実が創作に追いついた感はある

Claude CodeやCodexを使ってどんなに便利になっても、エンジニアはそれをさらに最適化・効率化するためにあれこれ検証して工夫するのでエンジニアリングの仕事は一生なくならないなとあらためて思う

ソフトウェアは人間がコードを書かなければいけない、という決まりはないので、AIアシスタントを使ってコードを生成して、それが許容できる振る舞いをして、リリースまでたどり着くのであれば、AIアシスタントのほうが人間より遥かに速い速度で開発をするので、人間の検査の速度が追いつかなくなり、それを「人間がボトルネックになる」と表現するのは至極真っ当。

AI-DLCのドキュメントを読んだ。週単位のスプリントではなく日単位でサイクルを管理する、というのはClaude Codeを使い倒した今だからこそスッと頭に入ってくる考え方。もう週単位の開発サイクルは「遅すぎる」なと感じる aws.amazon.com/jp/blogs/new...

Claude Codeにおける開発では人間が絡むところは軒並み全部ボトルネックになるので、人間がメンテする箇所は可能な限り順次AIに置き換えていくというのが基本戦略として重要と思う

去年までは下手にAI周りを追いかけることに必死になるより、思考力を鍛えたり基礎的な学問を学ぶ方が重要と思っていたが、昨年末にClaude Codeを触ってからひたすらClaude Codeだけ触り続けている。「今これを体験するのが一番重要な学びになる」というのが自分の直感

あるモデルによるバイブコーディングの限界サイズについて語るとき、Claude Code等のAIエージェント用ツールを使っているか、skillを作り込んでいるか、などで全然感覚変わってくる。これらのツール・技術の有無で限界と感じるコード行数は普通に1、2桁変わると思う

Sonnetの作業自体は完了したが途中で一つのエラーを無視していたので、それをOpusにレビューさせてスキルを改善させようとした。ところがOpusはそのレビューにおいて、発生したエラーを問題なしと判断していたため、私がそれをOpusに指摘して元のスキルを修正させた。さらに、「最初にレビュー依頼したときにエラーを問題なしと判断した理由は何かを考え、再発防止策を考案して作業ログレビュー用のスキルを改善して」と指示して改善させた。その結果、Opusは「批判的思考が欠如していた」という自己批判に至った。そうだ、それでいい

作業的なタスクをSonnetだけに任せられるようになると、Opusに実験的な機能追加や新規開発の計画を任せられるようになるな。シニアに手順書作らせたり検証ツールを作らせることでジュニアが自分でも作業をこなせるようになり、その分シニアの工数が空いて新しいことをシニアに任せられる

Claude CodeでOpusとSonnetを行き来するSkillのPDCAサイクルが安定してきたので、Opusによる検収作業を抽出して検証ツールに落とし込んだ。これでSonnet単体で作業検証ができるようになったのでOpusなしでも安定した出力になった

Claude CodeでOpusとSonnetを使ってskillのPDCAサイクルを回し続けている。Opusでskillを作る、そのskillを使ってSonnetに作業させる、作業ログをOpusにレビューさせてミスの再発防止などを盛り込んでskillを改善する、をひたすら繰り返している

Claude Max使い始めて1週間たつけど、ちょっとした便利ツールをほしいと思ったら作れるようになったので、これによって大幅な時間節約になるし、場合によってはお金の節約になる（そのような機能を提供する製品を買わなくて済む）から余裕で元取れるなって思った

Claude Max 5x 1週間で個人ゲーム開発した成果 364コミット スプライト生成: キャラ48体、雑魚敵2体、ボス2体、オブジェクト5つ、マップタイル3種類 faviconとOGP生成 バックストーリー60本くらい PWA対応 細かいUIと翻訳ミスいろいろ修正 成果としては十分すぎるな。AIなしなら余裕で1年かかるか数十万円、数百万円といった金がかかる分量だ

知識のあるエンジニアが何かのアイデアを出そうとするときに、無意識のうちに実装イメージについて考えていたような気がする。 例えば「新しいチャットツール」というのを考えたときに、なんで「チャットツール」で考えてしまうのかというと、そういうものの方が自分で作れるイメージができるから、というのがあった気がする。 AIでこれだけ実装へのハードルが下がったとき、もっと抽象的なアイデアを研ぎ澄ませていった方がいいのかもしれない。 今までは単なるふわっとした夢物語でしかなかったようなアイデアが、短期間で具体的に動くものとして出てくることを考えると、アイデアの出し方ももっと変わってくる気がする

ブログ書いた shiumachi.hatenablog.com/entry/how-to...

5億年ぶりくらいにブログ記事書いた shiumachi.hatenablog.com/entry/claude...

ITエンジニア界隈が治安悪い、みたいな投稿をみかけて、てっきりLinusが久々にブチ切れた話をしてるのかと思ったらどうやら違うらしい（細かい事情は追いかけてない）。Linusブチ切れ初見勢がビビッて「ITエンジニア界隈は治安悪い」って思うのなら気持ちは分からなくはない。昔のLinusを知ってる人はむしろ平常運転に戻ったという懐かしささえ感じるのではなかろうか

AIが理解できない要件や設計を伴う開発は今後は淘汰されていくのかもしれない。今までは、「過去の積み重ねを簡単には捨てれない」という前提の元、いびつであると知りながらもそうした要件や設計を受け入れて開発してきたシステムがあったが、AI支援による開発が当たり前になったときに、その恩恵を受けれなくなるというのはかなりの痛手になるのではなかろうか。もちろん実際にはそうしたシステムは特に基幹システム等においてまだまだ生き残るであろうが、それによる生産性の差は無視できなくなる気がしている

2009年発行（原著）の情熱プログラマーに、「コーディングはもう武器にならない」という言説があった。これは、「 『情熱プログラマー』はなんて先見の明があったんだ」ということではなく、むしろ逆で、「コーディングがこれから武器にならない、という言説には注意せよ」ということだなと思った。少なくとも、ITエンジニアの武器としてコーディング力が無用になるということはここ16年の間全くなかった

開発初心者向けにおすすめの本を紹介するとき、ここ最近は「とりあえずリーダブルコード読め」って言ってばかりいる。他にも勉強してほしいことは山ほどあるけど、とりあえずリーダブルコードの思想を頭にインストールしないとその先が続かない

deepwiki.com DeepWikiを使っているが本当に体験がいい。公開リポジトリのコード解説ドキュメントを図表つきで自動生成するのもすごい便利だが、とにかく検索が強烈。エラーメッセージを突っ込むと解説つきでソースコードを検索してくれる。ユーザー向けドキュメントはともかく、開発者向けドキュメントは完全にAI生成の時代になったと確信した

他人がAIで生成した文章を読んでも目が滑るのと同様に、他人がAIで生成したコードを読んでも目が滑って全く頭に入ってこない気がする

「名前重要」というのはMatz氏による格言だが、AI時代になってより一層重要になってきている気がしている。コードはAIに書けても、適切な名前づけを全てAI任せにするのは難しい気がしている。もちろん、さして重要でないコードや既に概念が固まっているシステムの周辺などで副次的な命名をAIが自動で行うこと自体は何も問題はないが、一つのシステム、プロダクト、プログラム、サービスなどの中核やその基盤となるコンポーネントを全てAI任せで命名するのはかなり難しいように思う。もしそれができているのなら、それはおそらく別の概念の周辺システムにすぎないか、あるいは既存の概念の模倣ではないかと思われる

AI、結局のところ単なる外部デバイスなので自分の内「臓」CPUとストレージに比べるとレイテンシが重すぎる。いちいち外部通信しないでも処理できる能力を底上げしないといけないなと感じている

郵便番号でさえ、発足当初は大学教授などが「人間性が失われる」という批判をメディアに投稿してたので、新技術や新システムについての社会的影響に関する意見には基本的に懐疑的な目で見ている

どれだけ思考タスクをAIに任せられるようになっても、その中心部分には必ず人間の思考が入る、というのが私の思想。ITシステムが様々な処理を自動化していてもそれを創造したのが人間であるのと同様、AIがどれだけ高度な思考を自動的に行えるようになったとしてもその思考の出発点には必ず人間の思考が入ってくると思っている。人間の思考が思考システムの一部に含まれる以上、処理能力に劣る人間がボトルネックになるのは明白であるし、逆に言えば人間の思考速度を向上させるだけでトータルスループットは大幅に上がると思っている

多くの人が「いかにAIに仕事を丸投げするか」に興味が向いている中、自分はずっとAIで自分の能力をどうやって強化していくか、というテーマについてばかり考えている

いくつかのAIモデルに触っていると、そのAIモデルのクセが分かる。このクセを知っていると、状況によって仕方なく特定のAIモデルを使わざるをえないときにそのクセを考慮したプロンプトを書ける。わざわざ人におすすめするようなスキルではないが、あればあったで意外と便利な知識だなと感じる

抽象化というのは、その人のセンスがもろに出てくる思考作業だと思う。ITの世界だけでも、コードの抽象化、機能の抽象化、コンポーネントの抽象化などさまざまな抽象化があって、そこには絶対の正解はない。IT以外の分野でも、例えば企業の組織編制や商品のカテゴリー分け、顧客のセグメント設計など様々な抽象化がある。AIに抽象化を部分的に任せても、最後は人間がその抽象化の是非を判断することになるわけで、そこにはその人の感性が入ってくる

Gemini 2.5 Pro Exp 03-25 を早速試してみた。デフォルトで推論を行うことと、デフォルトの出力トークンが65535に設定されていて前バージョンの8192から大幅に増えていることを確認。それ以外の細かい違いはもう少し触らないとわからない。他の最新モデルと同様、人間が少し触るぐらいだともはや出力のクオリティの差は測れなくなってきている気がする

AIに仕事が全て奪われるとは全く思っていないのだが、一方で「老後はOSS活動に勤しんで、ゆっくりコード書いて過ごしたい」みたいなエンジニアの夢は多分きっと叶うことがないんだろうなとふと思った

「似てるけど違うデータ」についての解像度の高さはエンジニアの実力差が表れるところと思う。フィールド名が一見同じように見えてもそれらのセマンティクスが異なるなら統合してはいけないし、仮に現在全く同じであったとしても将来変わりうる可能性があるのならやっぱりそれらはひとまとめにしてはいけない、というのはいろいろ経験を積まないと体得できない感覚と思う