/model opusplan という設定がある。これを設定すると、plan モードの時だけ Opus が使われて、それ以外では Sonnet が動くようになる。
普段からFableを使った開発ではどんなタスクでさえスムーズに進む…。 しかし19日を待たずに、悲しいWeekly Limitが来たら嫌ですよね…？
そう思って、このopusplanをfableでやれたらなとおもってAIに聞いてみた。
AI「あります」 「ホント？！」
なんと、Claude Code は環境変数でモデルを差し替えられるらしい。
ANTHROPIC_DEFAULT_OPUS_MODEL と ANTHROPIC_DEFAULT_SONNET_MODEL を
指定しておくと、opusplan プリセットが内部的に使うモデルそのものを
差し替えてくれる。
これを応用することで、こういった alias を用意できる。
alias fableplan='ANTHROPIC_DEFAULT_OPUS_MODEL=claude-fable-5 ANTHROPIC_DEFAULT_SONNET_MODEL=claude-sonnet-5 claude --model opusplan'
fableplan を叩けば、plan モードのときは Fable、それ以外は Sonnet で動く Claude Code が立ち上がる。
設計では Fable を使って、実装は Sonnet 5 を使って爆速開発。ぜひやってみてください。
]]>それでは大事なときにパワーを発揮出来ない。 このままではいけないので、少しずつ身につけてきた体力コントロール方法を言語化しようと思う。医学的な根拠を厳密に調べたわけではないので、あまり過信しすぎないようにしてほしい！とくに後半は血糖値まわりの話も出てくるけど、糖尿病などの持病がある人は、ここに書いたことより自分の主治医の指示を優先して頂きたい。
疲れやすい体というのは、代謝が関係していると思っている。代謝の低下によって、体がうまくエネルギーを使ってくれなくなる。そうすると、エネルギーが有り余っているはずなのに、だるい、起きれない、疲れる、眠いなどの症状が出てくる感じがある。
改善策としては、毎日カーディオ（有酸素）運動をすることによって、体が脂肪を消費しやすくなるように少しずつ改善していく。とにかく脂肪をエネルギーに変えやすくすることが大事。
高強度の運動だと、使うエネルギーに占める糖質の割合が増えるらしい。ただ、だから脂肪が燃えなくて効果がない わけではなくて、高強度は総消費カロリーも大きいし心肺も鍛えられる。ここでゆっくりを勧めるのは、体力が落ちてる状態でいきなり追い込むと足腰を痛めて続かないからで、脂肪燃焼のためというよりは続けるため。糖質のストックが切れれば脂肪が使われる量は増えるけど、筋肉が先に分解されるわけではないらしい。
だから無理な高強度はせず、ゆっくりと時間掛けてするのが足腰に普段かけずに良い。
筋肉は体の中で糖をいちばん多く受け取ってくれる場所で、筋肉が多いほど食べた糖をうまく片付けてくれる（インスリンの効きが良くなる）。余った糖は肝臓で脂肪に変えられて溜まっていく（いわゆる脂肪肝）から、筋肉がその糖を先に使ってくれると肝臓に回る分が減る、という理解でいる。
とはいえ、筋トレは追い込みすぎると回復が追いつかず逆効果になる（筋肉は休んでいる間に育つ）ので、ほどほどで良い。一週間に2日、少しだけやるくらいでも良い。 筋トレは少しずつやって、余裕がでたら回数を増やしていくで良い。
全体的な比率としては毎日運動してよく、カーディオ:筋トレ 9:1 くらいで良い。
ここまでやって一ヶ月頑張れば、ある程度体は動かしやすくなってくる。運動すると脳のシナプスが活性化して頭の回転も速くなる（ワーキングメモリが増える）と思う。
とりあえずここがスタート地点！ ちなみに言っておくと筋肉指標として SMM(骨格筋肉量)をKPIとして追いかけるとメンタル的にも良い。
ここから大事になってくるのがタイムマネジメント。「疲れ」とは何かを真剣に考える。
いきなり厳しい見出しを付けたわけだが、目が覚めた瞬間をHP100% として、そこから少しずつ減っていく。基礎体力をつけず極限まで運動しなかった場合、なんと8時間も体が持たなくなる。座ってることすら辛くなって、ベッドでパソコンカタカタしたくなるわけだ。
横になってパソコンしてればまだいけるぜ！なんて思ったらもうおしまいだ。基礎体力が足りていない。HP100% が起きた瞬間として、 もう限界！となったときはHP0%として、だいたいそれは何時頃だろう？
無闇に血糖値スパイクという言葉を乱用してはいけないことは認識している。そういった言葉が話題になるくらい 「食後には血糖値があがりやすい」ということを歳を重ねるごとに気になり始めるものです。
炭水化物を抑えれば、そこまで影響ないこともあるけど、基礎体力がないとちょっとだけご飯を食べただけでも血糖値が上がりやすいことがある。
それが嫌で、朝ご飯を食べないで体調を整えてるけど、結局は昼ご飯を食べてガツンと眠くなるみたいなこともあるとおもう。朝ご飯を食べないことで朝の血糖値上昇を抑えて、気持ち悪くならずに行動できるようにする、という目的ならありなんだけど、朝を抜くと昼ご飯の血糖値の上がり方がかえって大きくなりやすい。前の食事が次の食事の血糖値を穏やかにする「セカンドミール効果」というのがあるらしくて、朝ご飯を食べておくと昼の上昇がゆるやかになる。三食に分けて食べるのは、血糖値の急な上下を抑えることに寄与している、という話。
どうしても三食とるのが難しいのであれば、昼はカップラーメン1個だけだったりでもいいのでなんでもいいのでちょっとでも食べたほうが良い。
基礎体力をしっかりつけて、人間が元気でいられる時間は11時間だと思う。 かなり運動していた時期でも13時間くらいだったと思う。そして、まだいけるからといって頑張りすぎると、基礎体力が減っていき11時間がキツくなってくる。8時間を下回ったらまずい。
なので、11時間は元気でいられる時間を維持できるように残りの可処分時間で運動の時間をとり入れるとよい。7時間睡眠だと6時間が可処分時間になる。通勤に毎日2時間使うとして4時間。1時間で料理をして残り3時間。お風呂で残り2時間〜2時間30分。
この残された時間の中で運動の時間としてしっかりと作ることが大事。運動を1時間やったとしても残された可処分時間は1時間〜1時間30分くらい。
しっかりとタイムマネジメントしないと難しい。
HPが100％あるのは起きた瞬間なので、まずやるべきことを朝に消化させる。仕事などで時間がロックされているのであれば、早起きは必須。夜ご飯のほうが血糖値があがりやすいので、朝ご飯多めにして夜少なめにするためにも朝ご飯は食べたほうが良い。
朝ご飯を食べたことによる血糖値上昇で朝つらいのは、慣れるまでは耐えるしかない。でも毎日運動して筋肉を付けると、筋肉が糖を引き受けてくれるし、運動した翌日はインスリンの効きが良くなって血糖値が上がりにくくなる（この効果は1日〜2日くらい続くらしい）。だから運動を続けていれば、昨日動いた分で朝ご飯を食べてもかなり楽になる。安心して食べて良い。
ミーティングなども朝にやったほうがいい、そのあとのNAを午後に考える事が出来る。 重要なものは体力に余裕があるうちにやっておくことが大事。
逆に朝すぐに出勤することで元気がある時間を勤務時間に充てることで見かけ上勤務時間+残業時間が長くとることも可能だが、朝ご飯を食べる機会を失ったり夜ご飯が絶対過食気味になるのでオススメ出来ない。
まだ体力があるので、もくもくと集中できるようなことをやると良い。基礎体力がないとここで限界が来ることもある。なんかだるいと感じたら、メンタルよりもまず先に運動不足を疑ったほうが良い。
体力があまり残っていない。惰性で続けても、生産性は落ちている。何かここで重要な事に気付いても、明日には半分は忘れてしまっている。 こういうときは、まだ可処分時間が残っているなら運動に当てるのがベスト。運動はワーキングメモリを必要としないから、ここで何か考えてたとしても寝て忘れることもない。
あと運動しながらでも頭の中で考えられるから、無理に勤務時間を意識しなくてよいと思う。運動中でもKindleを読んだりすることはできるので、そういった時間にすれば良い。
体力が増える瞬間、減る瞬間には細かな依存関係がある。食後の血糖値上昇はとくに扱いが難しいし、朝ご飯を食べなかったことによる血糖値の乱高下もそう。
そんな中時間を見つけて基礎体力をつけて体力の底上げをする。そして体力は、脂肪燃焼のメモリ（燃焼しやすくなる）、筋肉によるものなどうまく見て整えないといけない。
運動を持続的に行うと血糖値の乱高下は緩和されて、集中力が続くので絶対運動はした方がいい。
糖質を取らなければ血糖値はすぐには上がらないので、糖質を抑えるのも手ではある。ただ脳はエネルギーのほとんどを糖（ブドウ糖）に頼っているので、まったく取らないと脳の燃料が足りなくなる。
糖を全く取らないと急に眠くなるのは、たぶんこういうこと。血糖値が下がると、それ自体で頭がぼんやりして眠くなる。体は足りない分を脂肪（ケトン体）やタンパク質から作って補おうとするけど、この切り替えは一瞬では終わらない。切り替わるまでの間、脳に回る燃料が一時的に足りなくなって、強い眠気になる。低糖質を始めた最初の1週間くらいにだるくなる「ケトフルー」と呼ばれるやつも、同じ切り替えの時期の症状らしい。
とくに寝不足のときはまずい。 寝過ぎても逆に疲れはでてしまう。寝過ぎた場合、起きた瞬間からHPは100%ではない。長く寝すぎると体内時計が乱れて、起きてもだるさが残る（いわゆる寝だめの副作用みたいなもの）らしい。
無理に夜頑張り過ぎると疲れが次の日に繰り越されるか、寝る時間が過ぎて寝不足になったりする。
自分は以前よく休憩をよくすることがあった。休憩、何もしない時間。もしくはだらだらとYoutubeショートを眺めたりするだけで横になっているだけの時間。気付いたら1時間2時間たっている。
そんなのを見たとしても、自分が影響を与えられるキッカケにすらならないものにそういった時間的投資をするべきではないことは頭ではわかっているんだけど、してしまう。
なぜ人はこんな無駄な時間を過ごしてしまうのか、それは、チルタイムを求めてしまう原因は、基礎体力が切れているけどやるべきことが残っているから。
夜になると、いろんなことに気付く、あれもやらなきゃ、そういやこれやってなかった、こういうNAあった。そして今日のうちに片付けなきゃ明日やれない。となる。そして寝付けなくなる。
明日で、いい
ブギーボードを買って、そこに書いておいて、HPが100%の時にやればいい
休めば体力が回復するのはそうだけど、100%になるわけじゃない。それはシンプルに睡眠時間を削って違う時間で不効率に時間消化しているだけ。無理に休憩することなく、運動の時間をしっかりと確保し、基礎体力をつけ、しっかりと集中することが大事。
そうやって少しずつ元気に活動できる時間を増やしていくのが重要だとおもう。
これに気づけないと、どっかで限界が来る。遺伝的に体力が有り余っている人はもちろんいるだろうけど、あとは運動を諦めて食事に制限を掛けずエネルギーを絶えず食物から取るというスタイルもあるだろう。
その場合の血糖値コントロールだけど、コーヒーは要注意で、カフェインはむしろ血糖値を上げやすくする（インスリンの効きを一時的に下げる）という報告のほうが多いので、緩和目的にはあまり勧められない。食物繊維（イージーファイバーみたいなの）を食事に混ぜるのは、糖の吸収がゆるやかになるので理にかなっている。あと確実なのは食後に軽く動くこと（散歩でも）で、これは血糖値の上がり方をしっかり抑えてくれる。
体力があるうちは、頭の中の考え方の工夫によって対策できているが、それだけでいけなくなってくる。
これは年齢的なものではないと思う。最初に年齢の話をしておいてだけど、体力は運動でつけることが出来る。自分はリモートワークをコロナ期に長年しすぎて体力が落ちてしまってかなり大変だった。
しかも、運動する時間が全く取れず、かなりピンチだった。今ある体力を犠牲にした頑張りはいつか限界が来るので、体力はしっかりとコントロールしたい。
]]>考えてみると、これが記事というものの本質な気がしています。人間は、自分で思っている以上に、その文章がどこから来たのかという「where」を重視している。そこで AI に記事を書かせるのはやめて、代わりに学習資料を作らせることにしました。学ぶのは自分で、記事も自分で書く。いま試している、その運用の話です。
AI が書いた記事はすぐ分かる、とよく言われます。ただ、本質はそこではなくて、AI が描いた絵と同じ問題なのだと思います。誰が書いたのか分からないというより、誰も書いていない。
とはいえ、AI の文章そのものを否定したいわけではありません。AI の文章であっても、そこに意図を込めることはできます。意図の充填率が 100% を超えたとき、その記事にはちゃんと「where」が宿る、と考えています。目安は単純で、AI が生成した文章の文字数を超える分量のプロンプトを書くこと。そこまで意図を注ぎ込めば、それはもう自分の文章と言っていいはずです。
逆に言えば、「Go の記事を書いて」の一行から出てきた記事は、充填率がほぼゼロということになります。
そこで AI の出番を、記事そのものではなく前工程に移しました。流れはこうです。
最初の題材は Go にしました。Rails と比較する形で学習資料を出してみたところ、Rails と Go は本当に真逆なんだと実感しました。Rails は言語ではなくフレームワークです。では Go は、フレームワークがなくてもよい言語としてなぜ成立しているのか。資料はそこの本質を捉えていて、わかりやすいドキュメントになったと思います。
作った資料は、このサイト内の非公開パスに Basic 認証をかけて置いています。
正直なところ、無機質な Markdown を読むのに限界がきていました。AI の生成物は HTML で読みたい。認証付きの自分専用の置き場をサイト内に用意したことで、AI の生成物をいつでも読めるようになってきました。こういうことは Qiita や Zenn ではできないので、自前ホスティングのメリットだと思います。
しかも自前ホスティングは、月々 1,400 円くらいでも実現できます。AI を動かしているのはローカルのマシンで、外からは Remote Control で操作しています。AI 自体をサーバー内で動かせばもっといろんなことができるはずですが、あえて格安サーバーを選んで、SSG（静的サイト生成）でやることにしました。
この運用で使っている Claude Code のスキル定義は、nekolas.dev/code/learn-then-blog に置いてあります。ワークフロー本体（learn-then-blog）と、Basic 認証付きの自分用本棚への公開手順（study-book-publish）の 2 つです。
AI には自分専用の教材を作らせて、学ぶのは自分、書くのも自分。どうしても AI に文章を書かせるなら、生成される文字数を超えるプロンプトを書いて意図を充填する。この分担なら、AI の便利さと自分の記事であることを両立できるのではないかと思っています。
Go を学んだ結果の記事も、追って書くつもりです。
]]>/ide）が無い私は tmux のタブ（ウィンドウ）ごとに Claude Code のセッションを開いています。Claude に作業を頼んで、待っている間は別のタブで自分の作業をする。すると、Claude がいつ終わったのか分からない。タブを戻ってみたら、とっくに終わって待っていた、となりがちです。
そこで cc-tmux。Claude が考え中・作業中のあいだだけ、その tmux タブを赤くしてスピナーを回します。終われば元の色に戻る。視界の隅で分かるので、通知音もポーリングも要りません。
仕組みは Claude Code の hooks だけです。Claude Code はプロンプト送信やツール実行、応答完了のタイミングでスクリプトを呼んでくれるので、そこで tmux のウィンドウオプションを書き換えています。常駐デーモンはいませんし、tmux の外で起動したときは何もしません。ついでにタブ名も Claude のセッション名に追従させました。/rename すればタブ名も即座に変わります。
Claude Code には IDE 連携があります。VS Code なら公式拡張を入れると、いま開いているファイル・カーソル位置・選択範囲が Claude に伝わる。「この関数を直して」の「この」が通じるようになる機能です。
ただ、私のエディタは Zed です。VS Code は重いうえに、最近は Copilot が前提のような作りになっていて、うっかり有効になってしまいそうな気配もある。その点 Zed はターミナルまで軽快で、レンダリングがとにかく速く、誤操作も少ない。気に入っているのですが、Claude Code の IDE 連携だけがありませんでした。
無いものは仕方ないので、zed-cc-ide という Zed 拡張を書きました。プロトコルは VS Code の公式拡張と同じで、~/.claude/ide/<ポート>.lock にロックファイルを置き、ローカルの WebSocket で MCP を話すと、Claude Code の /ide が見つけてくれます。Claude Code 側からは、IDE 連携がもう一つ増えたように見える寸法です。
面白かったのは Zed 側でした。Zed の拡張 API には、エディタのイベント（ファイル切替やカーソル移動）を受け取る仕組みがまだありません。代わりに、拡張は language server を登録できます。なので連携サーバに language server のふりをさせて起動することにしました。ファイルを開けば LSP の通知が来ますし、Zed は内部で codeAction などを頻繁にポーリングしてくるので、そのリクエストに乗っているカーソル位置や選択範囲を拾い、デバウンスして Claude へ送ります。
正直これはハックで、Zed の内部挙動が変われば壊れます。診断情報（diagnostics）も Zed が拡張に公開していないので送れません。それでも「開いているファイルと選択範囲が伝わる」だけで、Claude とのやりとりはだいぶ短くなります。
サーバ本体は Rust で 1300 行ほど。Zed 拡張（WASM）は、それを起動するだけの薄いランチャーです。
作ったのは Claude Code のための道具ですが、書いたのもほぼ Claude Code です。私は仕様を決めて、動かして、文句を言う係でした。Claude Code 役のモック（mock_claude）も作らせて、実物の Zed と往復させながらテストしています。
コードは nekolas.dev/code/claude-zed-tmux に置いてあります。git clone もできて、MIT ライセンスです。インストール手順は README をどうぞ。
そうなる前に、特に溜まりやすい広告メールを Google Apps Script で自動削除するようにしました。コードは実質 2 行です。
普段、不要なメールはショートカットの Shift+# でその場で削除しています。ところが広告メールはタブが分かれていて、自動的に「プロモーション」へ振り分けられます。すると逆に、広告メールだけが削除されずに残り続けることになります。
フィルタを使う手もありますが、フィルタでできるのは受信時の即時削除までです。「3ヶ月経過したら削除」のような時間差の削除は、標準ではできません。
そこで、Google Apps Script の定期実行で、古くなったプロモーションメールを削除します。
Gmail の検索演算子は、Apps Script の GmailApp.search() にそのまま渡せます。category:promotions でプロモーションカテゴリ、older_than:3m で「3ヶ月より古い」を指定して、ヒットしたスレッドをまとめてゴミ箱へ送るだけです。
function deleteOldPromotions() {
const threads = GmailApp.search('category:promotions older_than:3m');
threads.forEach(thread => thread.moveToTrash());
}
削除といっても、moveToTrash() はゴミ箱に移すだけです。ゴミ箱に入ってから 30 日経って、ようやく完全に削除されます。
であれば広告メールを全部ゴミ箱に放り込んでも楽なのですが、念のため 3ヶ月で設定しています。さすがに 3ヶ月見返していないなら、必要なメールではないはず。心配なら 1 年に伸ばしてもいいかもしれません。
Apps Script のプロジェクトは、Chrome のアドレスバーに script.new と入れるだけで新規エディタが開きます。これが一番速いです。
script.new を開く手動実行で古いメールがちゃんとゴミ箱に移るのを確かめたら、あとは自動化するだけです。
エディタ左の時計アイコン（トリガー）から、時間主導型のトリガーを足します。
deleteOldPromotions一度に全部消えるかと思いきや、実行してみると 100 件ほどしか削除されませんでした。Apps Script 側の実行制限なのか、Gmail 側のレートリミットなのかは分かりません。
それでも、何回か繰り返して実行していくと、少しずつ削除されていきました。だから 1 日 1 回の自動実行で回し続ければ、いずれ古いメールは削除しきれるのではないかと思っています。
検索クエリを少しいじれば、掃除のルールは変えられます。
older_than:1m でもっと頻繁に、older_than:6m でゆるめにcategory:social を足せば SNS の通知メールも対象にmoveToTrash() の代わりに thread.markRead() で既読化だけにとどめる手もあるひとつ注意点として、プロモーションにはたまにログイン認証のような必要なメールが混じることがあります。だからこそ、即時に全部消すのではなく「3ヶ月経ったら」という運用が自分には合っています。
削除ボタンをいちいち連打する必要もなくなるので、とても楽な方法です。
]]>私はこれまでの過去の経験で、DevOps に非常に興味を持って取り組んできました。特に、DevOps を進めるにあたって「何から始めるべきか」という問いに対して、私はCI を先に作り始めるということを重視してきました。
なぜ CI からなのか。それは、CI の構築を後から行うことが非常に大変だからです。複雑に組み上げられたシステムから後付けで CI を作っても、正しく全てがテストされていることを保証することは難しくなります。だからこそ、まずは CI を作り、TDD（テスト駆動開発）で開発を行うことが重要だと考えています。
DevOps を CI から始めることは技術的な側面ですが、組織としての DevOps の考え方も私は大好きです。
もともとエンジニアは、自分の開発効率の改善などを自分で行うことが多かったと思います。しかし、それを組織全体で行うと組織が大きくスケールする可能性があります。昔から社内 LT 会などを実施することで、ナレッジを共有し開発効率をチームや組織単位で改善するような取り組みも増えてきました。
しかし、これらはボトムアップ的な動きであるため、組織としての仕組みとして DevOps を進めるにはまだ弱いと感じていました。
実際に、DevOps を組織として進める役回りになったことが少しだけありますが、なかなか直接的な生産性に寄与することが難しく、「これなら、各チームの CI を改善したほうがいいのでは？」と思ったこともありました。しかし、さすがにそれだけを行うことは難しく、非常に苦労した思い出があります。
ここに関しては、どうすればよかったのか今でも悩んでいます。
しかし、時代は変わりました。AI の進化により、CI の改善やテストの自動作成などが一瞬で終わるなど、かなり開発体験が効率化されてきていると感じます。
AI を使うことによって、これまで苦労していた部分が大幅に改善されてきています。DevOps によって直接的な生産性の改善として、CI の改善やテストケース作成の自動化などの効率化が期待できますが、DevOps における運用者の効率アップも期待できると感じています。
まず、DevOps において運用者がどういった作業をこれまでしてきたでしょうか。
運用者は、業務領域として以下のような作業を担ってきました：
これらの作業は、非常に専門的な知識が必要であり、また、手作業で行うことが多かったため、時間と労力がかかるものでした。しかし、AI の進化により、これらの作業も効率化される可能性があります。
これまで、人間の手によって開発生産性の改善などエンジニアリングに関するものは、人の手では限界がありました。そのため、その改善はチームに留まることが多く、組織全体としてスケールすることが難しかったと思います。
しかし、AI の進化によって、プラットフォームエンジニアリングといった文脈などでも言われているように、DevOps を大規模に組織的に行うことが可能になってきていると感じます。
そのスケールが行える部分が、エンジニアの中でも特に運用エンジニアの部分ではないかと考えています。
運用エンジニアは、稼働しているプロセスの監視や障害対応を行うにあたって、開発しているサービスに障害が発生する前からその問題に気づけるようにしたり、ソースコードや品質の問題を事前に検知することが求められます。
そのためには、開発エンジニアが Ops の観点でコードを書いていくことが求められます。そういったときに、Cursor ルールで、Ops の観点のコード規約を追加するなどを行うことで、保守性の高いコードを書くことができるようになります。
また、CI 上に Ops の観点によってプロンプトが設定された AI Agent を組み込むことで、CI の中で保守性の高いコードを書くことが可能です。
それにより運用エンジニア自身も AI Agent を活用し、人間の目では見つけることができなかった問題を事前に検知し、障害が起きる前から未然に防ぐ可能性が高くなっていると思います。
これまで、CI や監視ツールの進化によって、ある程度は補っていたものではありつつも、人間の目によって保守されてきた部分が、AI の進化によって、より効率的に行えるようになり、それが組織全体へのスケールが可能になってきていると感じています。
DevOps の考えをこれまでは人間が守ってきましたが、チームではなく組織全体で守ることはスケールに限界がありました。
しかし、CI 上や監視ツールに AI Agent を組み込むことで、人間では限界だった部分を AI が補完し、組織全体での DevOps の実践が可能になってきていると思います。
AI 時代の DevOps は、単なるツールの進化ではなく、組織のスケーラビリティを根本的に変える可能性を秘めています。これまで個人やチームレベルでしか実現できなかった改善が、AI の力によって組織全体に波及していく。これこそが、真の DevOps の姿なのかもしれません。
この記事は、実際の DevOps 経験と AI 技術の進歩を踏まえた考察です。皆さんの組織ではどのような AI 活用をされていますか？ぜひご意見をお聞かせください。
]]>これまで長らく Github Copilot というツールを愛用してきましたが、AI エージェントという革新的な技術の登場により、私が知っているプログラミングの世界が根本的に変わろうとしていることを、日々実感しています。
今回の記事では、この変化について私なりの考察をお伝えします。
まず最初に、私の AI 活用の歴史について少し話します。AI を活用したプログラミングツールとしては、かなり早い段階から Github Copilot を使っていました。
Github Copilot は、多くの開発者にとって既に馴染み深い存在だと思いますが、正式には「AI が支援するコーディングアシスタントツール」として位置づけられています。このツールの登場により、私のコーディング体験は確実に向上しました。
しかし、ここで一つ疑問が浮かんできます。そもそも「コーディングアシスタント」とは、具体的にはどのような存在なのでしょうか？
コーディングアシスタントとは、人工知能（AI）の力を借りて、私ソフトウェア開発者のプログラミング作業を様々な側面から支援してくれる、非常に心強いツールのことです。
具体的には、以下のような機能を提供してくれます：
この中でも、特に日常的に恩恵を感じているのは「コードの自動補完・生成」機能です。この機能により、開発効率が飛躍的に向上したことは間違いありません。
実は、ここ最近になって、私が行う「コードを書く」という行為そのものが、知らず知らずのうちに大きく変化してきました。
「AI エージェント」という言葉を聞いたことはありますか？一見すると、AI エージェントと AI コーディングアシスタントは非常に似ているように思えるのですが、実際に使ってみると、その違いは想像以上に大きいということが分かってきました。
まず、現在の多くの AI コーディングアシスタントについて整理してみましょう。これらのツールは、言うなれば「非常に優秀な指示待ちアシスタント」のような存在です：
もちろん、これでも十分に素晴らしい支援を受けることができるのですが、より大規模な開発作業を考えた時には、どうしても物足りなさを感じることがありました。
一方で、AI エージェントは従来の AI コーディングアシスタントとは根本的に異なるアプローチを取っています：
この違いは、実際に体験してみると本当に驚くべきものがあります。
AI エージェントの最も印象的な特徴は、まるで経験豊富な人間の同僚のように振る舞ってくれることです。これにより、私開発者の負担は想像以上に軽減されることになります。
これまでの AI コーディングアシスタントを使う際には、以下のような配慮が必要でした：
これに対して、AI エージェントは以下のような革新をもたらしています：
技術的な背景として、DeepResearch のような先進的な技術により、AI エージェントは複数のプロンプトを自発的に分割し、段階的に必要な情報を収集することができるようになっています。これにより、私開発者は複雑な指示の出し方を覚える必要がなく、自然な言葉で要望を伝えるだけで、大規模なコード生成が可能になりました。
つまり、理論的には、たった一つの自然な指示だけで、完全なアプリケーションが完成してしまうことも夢ではないのです。
ここで、私自身が少し勘違いしていた点について正直に話します。AI エージェントというと、Devin のような製品が有名ですが、私は当初、これらのツールは主に CI/CD パイプラインのようなバックエンド環境で動作し、「気がつくとアプリケーションが完成している」という魔法のような体験だけを提供するものだと思い込んでいました。
しかし、実際に調べてみると、AI エージェントの世界はもっと多様で身近なものでした：
そのため、一見しただけでは、AI エージェントと従来の AI コーディングアシスタントの違いが分からない場合も多々あります。
それでは、数多くある AI 支援ツールの中から、真の AI エージェントを見分けるにはどうすればよいでしょうか。公式サイトに「AI エージェント」と書かれていれば分かりやすいのですが、実際の機能面での違いを理解することが重要です。
AI エージェント製品の多くは、AI を単なるツールとしてではなく、一人の有能な同僚のような存在として扱う傾向があります。製品の説明文や使用体験において、AI が主体的に行動する存在として描かれていることが多いです。
AI エージェントの根底にあるのは、「AI 自身が最適な判断を行う」という思想です。そのため、私使用者はどのモデルを使用するかという技術的な詳細を気にする必要がありません。
AI エージェントは、AI の能力を最大限に引き出すために、私開発者が技術的な詳細を意識しなくても済むように、非常に慎重に設計されています。
最後に、これからの時代を生きる私開発者への提案をします。
まずは、ぜひ一度 AI エージェントを実際に体験してみることをお勧めします。
もしあなたの AI 活用の知識が Github Copilot 程度で止まっているとしたら、「AI エージェント」と銘打っている製品に少しの投資をして試してみることで、プログラミングの世界に対する認識が根本的に変わる可能性があります。
私が直面している変化は、単なる技術的な進歩以上の意味を持っています。これは、プログラミングそのもののパラダイム転換と言えるでしょう：
この大きな変化の波に乗り遅れないためにも、今この瞬間から AI エージェントという新しい開発パートナーに慣れ親しんでおくことが、私開発者にとって非常に重要になってくるでしょう。
新しい技術への投資は時として不安を伴うものですが、この変化は避けて通れない未来の姿だと私は確信しています。ぜひ一緒に、この新しい時代のプログラミングを楽しんでいきましょう。
最後まで読んでいただき、ありがとうございました。あなたの AI エージェント体験が、素晴らしいものになることを願っています。
]]>Figma のこちらの記事では、リアクションを出す方法がありますが、実はこちらはカーソルチャットで出す方法があります。
カーソルチャットは、Figma のリアルタイムコラボレーション機能の一部で、他のユーザーがどこにカーソルを置いているかを表示し、コメントやリアクションを共有できる機能です。
カーソルチャットを使うには、FigJam 上で、「/」を入力して、カーソルチャットを開始します。
吹き出しが表示されますので、そこにメッセージを入力することで吹き出しが表示され、他の人にその吹き出しが見えるようになります。
カーソルチャットでリアクションを出すには、吹き出しの中に「fire」と入力します。すると、炎の絵文字が表示されます。
炎の他にも、様々なリアクションが用意されています。
例えば、<3 と入力するとハートの絵文字が表示されます。
リアクションは以下のようなものがあります！
<3: ハートサングラスをかけた絵文字は、カーソルチャットの吹き出しの中でしか見ることができないので、裏技的な使い方になります。
自分が調べた中では、👀 のリアクションは見つけることができませんでした！
ぜひ活用してみてください！
]]>入社エントリを書きました。 このエントリは、私がアプリケーション基盤を選んだ理由について書いています。 アプリケーション基盤エンジニアってなんだろうって方は読んでみてください！
]]>