hideb

多分技術系の話をするところ。

"やればできるエンジニア" でありたい

N 年ぶり数回目の投稿ですがポエムです。

弊社では近年 AI エージェントの利用が加速しています。

ありがたいことに最新のモデルをエンタープライズ向けのクォータで利用できる環境をいただけており、私もその恩恵にあずかりまくっています。

仕事はもっぱら Claude や Devin といった AI エージェントへの文脈提供とプロンプトを考えること、およびその成果を監修することにシフトしており、ここ数ヶ月は自力でコードを書いた記憶がほぼありません。

それはエンジニアとしてどうなのか…

これには人それぞれ多様な意見があることと思いますが、私の所感としては以下のような感じ。

  • AI が適切な振る舞いをするには、相応に適切な導き（文脈提供とプロンプト入力）が必要。
  • AI の成果を評価するには、AI が書いたコードを理解する力が必要。
  • AI の成果を AI にレビューさせるときも、どういう着眼点を持つべきかを指示するのはエンジニアの仕事。
  • なので結局、エンジニア然とした振る舞いは必要であり、これもれっきとしたエンジニアリング。

AI をうまく扱うために、エンジニアは AI の師匠であり続けなければならないと考えています。 そのためには、AI にやらせる仕事（書かせる言語やフレームワーク、サービスの使い方）を深く知っておく必要があります。

それはれっきとしたエンジニアなのでは？という考えです。 （と、自分に言い聞かせてるのかも…）

話は変わって、次のようなケースがあります。

  • 要件の指示は的確にできる
  • 成果のコードを AI の補助ありきで読み込み、AI が何を書いたのか理解することはできる
  • あまり詳しくない言語でも雰囲気は分かるので、レビューっぽいこともできる
  • ブラックボックステストは考えられるので動作検証もできる
  • なので製品として動くコードを AI に作らせることはできるが、「真に質が良いか」は実は自信がない

これが続くと「それっぽいコード」で仕事は回ってるように見えつつも、実はどんどん技術的負債が溜まっているかもしれないので怖いですね。

解決方法は簡単で、勉強してちゃんと AI の師匠になれるようにするだけです。

AI の師匠でありつづけられれば、それすなわち同等以上のコードを書く力が保てているということです。ある日突然会社が AI ツールを解約しても（スピードは落ちるかもしれないけど）変わらぬ成果を出し続けられるでしょうし、AI ツールを活用し続けていくにしても素早く高品質な成果を挙げられることになります。

つまり「"やればできるエンジニア" でありたいものですね」というお話でした。

私は最近研鑽をサボりがちなので自戒も込めてこの文章を書いています…

AI コーディングエージェントに慣れてきたので TIPS を挙げてみる

今年の夏に異動があり、それまでとは違う技術スタックのチームで働き始めました。

以前は主に Scala, Go, TypeScript のスキルが求められるチームで、拙いながらも雰囲気でなんとか食いついていました。(※Java 出身)

今度の新しいチームでは Perl スキルが必要で、ほぼ触ったことがなく、さっぱりわからんという状況に陥りました。

しかし幸運なことに弊社では Devin や Claude Code などの AI コーディングエージェントを利用できる環境が全社的に整備・推進されており、多くのエンジニアが活用しています。

私も AI の助けを得てなんとか新しいチームのタスクに取り組めるようになり…数カ月が経ちました。

今回は、日々 AI に助けてもらうなかで溜まってきた TIPS を紹介します。 せっかく AI がテーマなので、私が思う TIPS と、それを AI1 に解説してもらった情報を添える形式でいきます。

ちなみに本文中の「AI のお言葉」コーナーのみ AI が、それ以外はちゃんと人間が書いてます。 コードブロックをすっ飛ばすと5分くらいで読めるらしいです。

  1. 今回は Claude Code w/ Claude Sonnet 4.5 でやりました。これに Sonnet 4.5 使ったのもったいないな。↩
続きを読む

ポストモーテム読書会というものをしている話

はじめに

今日は、弊社 SRE 組織の中のとあるチームにて行われている「ポストモーテム読書会」という活動を紹介します。

TL; DR

  • 社内の障害対応時のポストモーテムをエクストリームリーディングする活動をしています。
  • O'Reilly Japan - SREの探求 のより身近なバージョンと言える。
  • 規模が似た組織の事例を追えるし、社内ゆえに情報は包み隠されることなく読める。

3行でまとまってしまってますが詳細は以下。

続きを読む

Azure ディレクトリは削除が面倒なので作成も慎重になろうという話

ほぼタイトルで完結していますが、なかなか面倒な経験をしたので情報共有まで。

TL; DR

  • Azure ディレクトリの削除は条件が多いため、作るときも慎重になりましょう。
  • グローバル管理者権限を持っていても、組織のライセンスベースのサブスクリプション *1 を追加していると最大90日かかる場合がある。

詳細

ある開発案件の都合で、検証に使用するディレクトリを分けたいということがありました。

ディレクトリを分ける必要があるかどうかの調査も含めてのことだったので「まずは作ってから考える」で雑にスタートしていたのですが、結局不要なことがわかり、削除することになりました。

削除対象のディレクトリには、残しておきたいリソースは無いため、気軽に削除操作をしてみると…

※本画像はヘルプドキュメントより引用

結構条件が多い。 このうちのほとんどは、削除操作を行うユーザーがグローバル管理者であればすぐに解決できます。

しかし「License-based subscriptions」がくせ者で、組織単位で適用されるライセンスが絡む操作であるためか

  • Microsoft365管理センターでの操作が必要
  • ライセンスのサブスクの削除に最大90日かかる

という特徴があります。

削除対象ディレクトリで Azure AD Premium P1/P2（試用版含む）、Microsoft 365 Business Standard、または Enterprise Mobility + Security E5 などを使用している場合がこれに該当します。

今回の私の場合は Azure AD Premium P1 の試用版が原因で、直ちに削除することができませんでした。 幸い、急いで削除したい理由もないので、大人しく90日待機して「無効」状態になるのを待つことにしました。

以上、ディレクトリは簡単に消せないので作るときも慎重になろうという話でした。

*1:Azure AD Premium P2、Microsoft 365 Business Standard、または Enterprise Mobility + Security E5 など。参考 : https://learn.microsoft.com/ja-jp/azure/active-directory/enterprise-users/directory-delete-howto#deprovision-subscriptions-to-allow-organization-deletion

python 複数の組み合わせパターンで文字列置換

コード断片

Python で複数の組み合わせパターンに従って文字列を置換する方法。

PHP でいうと

<?php
$orig_text = "AAA BBB CCC DDD";
$result = str_replace(
  ["AAA", "CCC"],
  ["えー", "しー"],
  $orig_text
);

// "えー BBB しー DDD"
echo $result;

みたいなことをやりたい。

Python でもシュッと出来るじゃろ～と思っていたのだが、意外とそうでもなかったのでメモしておく。

続きを読む

私にとってアウトプットとは何か

ひょんなことから

僕は技術エントリを自分のために書いているわけではない - Diary of a Perpetual Student

というエントリを読んで「なるほどなぁ、自分の場合はどうかなー」と考えたので文章にしてみた。

TL; DR

  • やはり自分のためのメモとして書いてる。
  • 内なる承認欲求モンスターの鎮静剤として書いてる。
  • 自己分析のために書いてる。

以下ポエム。オチはないです。

続きを読む

「SAML入門」を読んだ

id:kxn4t さんの「SAML入門」を読んだのでその感想をサクッと。

書籍情報

introduction-to-saml.tumblr.com

所感

SAML 仕様書の絵本 + ハンズオン

絵本といっても表紙とシーケンス図（フロー）くらいしか絵はありませんが、必要最低限の仕様が読みやすい言葉で取り上げられてます。

全12章の内訳は

  • (25%) SAML の概略と用語説明
  • (30%) SAML におけるリクエスト / レスポンス仕様の概要説明と、データの読解
  • (30%) 2種類ある認証フローの概要説明
  • (15%) ハンズオンとおまけの TIPS

といった感じ。

半分くらいは流し読みしてとりあえずハンズオンまで進めて、実際に開発するアプリケーションの仕様を検討したり実装したりする頃になってから読み返すくらいでも良いかも。

新しい技術に手を出すときに、公式の仕様書よりも先に日本語記事をググってからのほうがやりやすいというタイプの人にはうってつけだと思います。

表紙がかわいい

かわいいね

イラストレーターは たんたんめん (@km170) / Twitter さん。

おわりに

オライリー本なんかは、やるゲームが無くなってよほどヒマなときに相当気合を入れないと読めないんですが、これはスキマ時間でサクサク読めました。

以上。