2026-01-07

おためし

大抵の日は一仕事終えてから外でもう一度ご飯を食べた後に仕事をするんだが、今日はさすがに疲れてしまって何もできなかった。

この文章は音声入力を使って書いているんだけれど、あまりに精度が良くてとても驚いている。

と声をかけると改行するの面白いね。この辺どうやって認識してるのか謎だね。

AIにブログを書かせてどうのこうのって話はあるけれど、自分だとダラダラこうやって話をしてブログを仕上げるのを悪くないな。

2026-01-04

「脳が余る」という感覚

AIさんを2つくらいで回していると、作業的には進んでいると思いつつも「脳が余る」という感覚になることがある。作業を振ってやってもらっている間、考えることがなくなってしまうのだ。他に一つくらい時間を費やせる仕事がある方が、こういうやり方は合っている。

基本的に複数の仕事が進行するのが当たり前なので、相手が人間かAIかの違いしかない。AIの方がまだ手間がかかることはあるが、最近は前に比べてどうしようもない大失敗は減ったので気楽になった。

そういう時、文章を書くような仕事はありがたい。中途で手を止めても戻りやすいのだ。手順が重要な作業をやるとどこまでやったか、何をチェックしたかを忘れてしまい失敗することが多い。

だいたい私の場合

2AI + 文書整理や書く仕事
3AI で 1つ重要であとはサブ的に回す
4AI 以上は何か差し迫っている

この時「長時間任せたい仕事」については事前に設計書を十分に練り込んで、放っておいてもテストが通って完成するレベルに落とし込んで数時間放置してしまう（権限を許可するために見るくらい）。

自分主導でできるプロジェクトに関しては IssueにわざわざせずにとっととAIに書かせてPRすることが多い。

2026-01-03

年明け

古い友人とフグ食べて、実家に帰ったくらい。

そしてどうしてもやり切りたいあるシステムのためにAIさんに頑張ってもらうが、あと２日で終わる気がしない。AIさんあんなに頑張ってるのに。

やはりWebpackやcjsを引きずっているシステムをモダンに合わせるのは簡単じゃぁなかった。やることがどんどん増えてしまって終わらない地獄。

今年もよろしくお願いします。

2025-12-31

システム内メッセージを狙ったフィッシング対策

はじめに

C向けサービスにおいて、フィッシング狙いの不正メッセージが大量送付される事態に遭遇しました。その対策として実施した施策と、得られた知見を残しておきます。

有効だった対策

メッセージ送信のレートリミット
誘導先 URL の通報（Cloudflare やドメイン提供業者への連絡）
メッセージ内容によるフィルタリング
WAF のチューニング

詳細

レートリミットの実装

最初の攻撃時、システム側にアクセス制限がほとんどなく、大量の不正メッセージが送信されてしまいました。

対策として、一定時間内に一定数以上のメッセージを送信するとリミットがかかる仕組みを実装しました。リミット発動時には Slack に通知が飛び、メッセージログ画面への URL 付きで即座に対応できるようにしました。これにより、大量送付は防げるようになりました。

メッセージフィルタリング

送信されるメッセージの文章をチェックし、不正なパターンに引っかかるものはユーザーに表示されないようフィルターを実装しました。

メール内 URL のチェック

メッセージと共に送られるメールについては、メール内の URL を自サービス経由に変更し、チェックを通してからアクセスさせる形にしました。これにより開封率にも影響があった可能性があります。

誘導先への通報

人力でも効果があったのが、誘導先 URL を whois で調べて提供元へ通報することです。

Cloudflare: 連絡すると最短1分、長くても2日程度でブロックしてくれる
ドメイン提供業者: 合わせて連絡することで、他サービスへの攻撃も防げる

頻繁に通報されるとクレカがブラックリスト入りするなど、攻撃者の根っこを断つ効果も期待できます。この通報作業は半自動化の余地がありそうです。

おしまいに

複数の対策を組み合わせた結果、攻撃者は撤退したようです。

別途 AI を使ったモダンな対策の仕組みも準備していましたが、使われないのが一番なので、少々残念ですがよかったです。

システム改善には Claude Code が大活躍し、通報メールの作成でも LLM の世話になりました。数年前に比べればかなりスムーズに対応できたと思います。

AI 時代だからこそこうした攻撃も発生するわけで、一長一短でしょうか。

苦労しているシステム運用の担当の方に届きますように。

2025-12-31

2025年終わり

今年はこの何年かに比べてもとにかく仕事したと思う。若い頃の方が移り気だったので、仕事は好きだがある種程々のところがあった。

私の仕事は金にならないこともかなり多いので、やったからといって自分が裕福になったりはしないが、充実はしていた。

良い再会が多く、もともとアルバイトでその後もずっと付き合いのあった人が入社したり、1号社員が立ち上げた会社と同じ現場になり、弟子の弟子に会ったりなど、過去の行動からの繋がりが多かったように思う。

健康についてはなんだかんだで落ち着いていて、大きな病気もなく健康診断の結果も良好である。長生きしたいわけではないが、長患いだけはしないようにポックリ逝くのが目標である。

たまにサウナと水泳して、仕事前にスクワットする程度だが、やった方がいいことは見えてきたはずだ。特にスクワットは短時間でできる割に腰が痛くなくなっ膝が強くなったりと良いことが多い。

大変なこともあるが、なんとかやっていけていることに感謝して来年も全力投球しようと思う。

2025-12-27

仕事納め

12/26 が仕事最終日でした

弊社はフルフレックス制度なので、「基本的に」という前置きではありますが、昨日12月26日で業務としては終了いたしました。弊社が一次請けで責任を持っているシステムに関しては障害対応等での緊急の稼働はあり得ますがそれ以外の開発は一旦ストップしております。

ずっと継続したシステム運用をご依頼いただいているお客様に加え、新たに古い繋がりから生まれた大きなお仕事や、弊社を巣立ったメンバーと一緒の仕事が実現するなど、大変充実した一年でした。

みなさんありがとうございました。そして来年もよろしくお願いいたします。

納会にて

フルリモートメンバーなので集まって酒盛りのようなことはしていないのですが、短時間ちょっと会話するようなことは継続しています。あまりテーマなど求めずに雑談して終わることが多いですが、今年の話題はあとで振り返りたいかもしれないので少し残しておきます。

まず、知り合いに聞いたところによるといわゆる SES のJOIN条件が以前より高度になっているそうで、下手すると「現場経験5年以上」のような求め方をされるそうです。縁故で入ってしまう弊社では気付きにくいところですが、以前言われていた即戦力というのをさらに超えて、一般以上にできる人を求める傾向になっているのでしょう。

これは今後の採用にはかなり影響があると思うので、大変気になります。弊社はAIの台頭のタイミングから「一時受けのシステム運用含めた仕事」にウェイトを傾けているので、新たな人が入ってきた時にもシステム開発の現場に入りやすい土壌があります。一般のSES業者にはそういうところがないと思われるので、資金繰りの悪化が懸念されると感じました。待機社員が増えるとそのまま経営を圧迫するので、よほどの体力がないとこのタイプのSESは継続できないと思われます。

そういった世間の動きはあるとして、今後の受託システム開発においては「AIにコードを書かせ、レビューし、他のレビュアーに依頼してマージ」という流れになると思う為、これまで「コード書き」という属性だけで仕事できた人に居場所がなくなってきます。全メンバーにこの傾向は都度伝えていますが、改めて伝え直した次第です。

また、上位層のメンバーは「仕事を終わらせる」能力が求められますので、そのための見通しや根回し、並行して仕事を進めるための工夫、大ブレーキが起きないようなポイントについての考え方を改めて問答も交えながら確認しました。長く一緒に仕事している人には言葉としては根付いてきていると思われましたが、実践をより適切にやることが求められます。

少なくとも「開発に時間がかかる」という状態をAIがかなり解消してくれるため、見通しが立てやすくなったことは間違いなく、ボトルネックはほとんど人間であると思って良いでしょう。できるだけ事前にリリースまでの障壁を見通してアクションし、並行したタスク進捗をしてスムーズに完了させるのが理想です。

事前に資料など準備してなかったので、オンラインスライドにポイントを書きつつ進行しましたが、それなりの内容にたどり着けたと思います。

来年以降求められる現場の開発者像

現場の開発者として求められる姿は、AIの台頭で大きく変化したはずです。

AI に適切に指示して無駄なくコードを書かせることができること
書かせたコードをレビューして「とりあえず動く」で完成されたコードを適切に直させられること
上記を低コストで行わせる、タスク分解やプロンプトの技術

これは昔あった「カチャカチャ、ターーン！」というコード書きのイメージを大きく覆しています。そしてスキルとしては現場をリードしていたメンバー（テックリードなどリーダー格が多いはず）のスキルの一部になります。

ただし、対人ではないことから「人間とのコミュニケーションが苦手」という人にもできます。だからこそ現場の開発者の基礎知識として数えられます。

ちなみに2についてが開発者個人のスキルにかなり密接になるため、設計スキルを磨くのは必要でしょう。「どこに、何が書かれているべきか」「テストでは何をチェックすべきか」などをある程度持っている必要があります（この知識をもちろんプロンプトにするのですが、適切に遂行されたかチェックできないと意味がありません）。

コードをたくさん書いた経験がなくとも、単一責任やOpen/Closed などの原則、MVC（FatControllerを避けるなど）、疎結合を避ける設計の哲学、テスト容易性など、ベストプラクティスやアンチパターンから学べることが数多くあるので、優秀なレビュアーとなれれば活躍しやすいですね。

開発者としての自分

3年くらい前から「自分が現場の開発者としてどれだけできるか改めてチャレンジしたい」と思って、自身が外部のプロジェクトにJOINする方針に切り替えていました。当時色々と知り合いに相談させてもらってプロジェクトに入れてもらいました。ありがとうございました。

しばらく社長業を中心にしていたので最初はとてもしんどかったのですが、やっている途中でAIコーディングの現場への浸透があり、とても幸運でした。自分の現場感を持った上でAIの評価をして自分なりの付き合い方を決められたのは個人・会社双方にとって大きな利益でした。

今関わっているプロジェクトでも、一応現役25年続けた経験者として尊重していただきつつ、技術難易度の高い開発を任せてもらえて幸運だと思います。そして少し変わったこととしては、たとえば私だけが仕様を理解しているが技術難易度が低いタスクについて以前は「仕様を明文化して誰かにアサイン」のところ「仕様を書いてAIにお願いして仕上げる」に変わったことです。これは先のSESの話とも通じることで「仕様を書いてくれればコード書けます」という人がいても、頼むことはないということになります。

私の場合、https://github.com/ms2sato/agent-console を作ってから複数プロジェクトの複数タスクで並行稼働は容易になったので、ほとんどいつも複数のタスクを稼働させています（今も2-3タスクが動いてます）。そのラインに乗せやすい仕事は他人に依頼する必要がなくなるのですね。先に書いたSESで求められる人材の高度化はこういう部分で納得感が高いです。

「まだまだやれる」感は掴めたので、あと5年くらいは現場の開発者でいられるだろうか。