こんにちは。スパイダープラス株式会社でシニアエンジニアリングマネージャーを務めている新井です。昨年12月に入社し、特定の開発プロジェクトではなく、エンジニア組織を横断した仕組みづくりや組織づくりに携わっています。
スパイダープラスでは2026年4月、プロダクトにAIを組み込むための研究・実証を担う研究開発部を新設しました。新設からまだ数ヶ月ですが、社外のエンジニアの方とお話しする機会が増える中で、非常に強い関心を寄せていただいていると実感しております。
そこで、この記事では、研究開発部が取り組んでいるテーマや、立ち上げ期の組織をどう運営しているのかを紹介します。AIと部門立ち上げの組み合わせはよくあるケースかと思うので、業界に限らず、似たような取り組みを検討されている方に面白さと難しさが伝われば幸いです。
続きを読む
SREチームの平木です。普段はプロダクトのAWSのインフラ全般を担当しています。
ご存知の通り、本番インフラを運用していると業務のひとつにインシデント対応があります。メトリクスを見て、ログを追って、直近のデプロイを確認して……という切り分けは、経験に依存しがちで属人化しやすい作業です。
そこで、2026年3月に一般提供された AWS DevOps Agent（自律的にインシデント調査を行うエージェント）を検証しはじめました。最終的には「CloudWatchアラーム → 自動で調査 → 結果をSlackへ → ゆくゆくは復旧まで」を目指していますが、本記事はその第一歩として、セットアップと手動での調査を通じてエージェントの実力を確かめたところまでをまとめます。
続きを読む
こんにちは。プロダクト品質部の三好です。
この記事は、PoC の実装・検証から本稿の執筆まで、Claude と三好の協働により作成しています。要所要所の数字の確認や現象の評価は人の手で行っていますが、語り口や言い回しは Claude が大きく担っているため、表現の細部には脚色が残っているかもしれません。
ソフトウェア開発の各工程は、AI に任せられる範囲が広がってきました。 Claude の Skill を使えば、要求分析・実装・テストといった工程を個別に AI へ委ねられます。 さらにいまは、個々の工程を任せるだけでなく、複数のエージェントを束ねて自律的に動かす方向へ関心が移りつつあります。 オープンソースの OpenClaw は本稿執筆時点で GitHub の Star が 38 万を超え、それをベースにした Microsoft の Scout のような製品も登場しています。
ただし、話題の派手さと、実務で使えるかは別の問題です。 加えて、利用が広がるほど、AI のコスト最適化も事業の課題になります。
そこで、二つの問いを立てました。 第一に、要求分析からリリース判定までの各工程を、人手を介さず一本につなぐオーケストレーションが成り立つか。 第二に、工程ごとに品質とコストの釣り合うモデルをどう選ぶか。
具体的には、Microsoft の AI エージェント開発フレームワーク Microsoft Agent Framework を使い、各工程を担うエージェントを、V 字モデルの前進と手戻りを表すワークフロー・グラフに組みました。 このグラフを実行して Web 関数電卓を開発し、題材とグラフは固定したまま、各工程のモデルだけを Haiku・Sonnet・Opus に入れ替えて比較しました。
結論を先に述べます。
続きを読む
こんにちは。今月スパイダープラスに入社したエンジニアの熊瀬川です。
入社して最初の仕事は、配属されたプロジェクトのコードベースのキャッチアップでした。従来であれば「ドキュメントを読んで、分からないところを先輩に質問する」のが定番ですが、いまは手元にコードベースを丸ごと読めるAIエージェント（私の場合は Claude Code）があります。
先輩の時間をなるべく奪わずに、AIにどこまで「問い詰めて」キャッチアップできるのか。この記事は、入社1ヶ月の私が実際に試してみた正直な記録です。 うまくいったことだけでなく、うまくいかなかったこと、そして「やっぱり人との時間が効いた」という話も書きます。
続きを読む
こんにちは、プロダクト運用部CREチームの大畑です。
1年ほど前にブログ記事を担当しましたが、実は他にも「業務でのAIの使い方について」というドラフトを書いていました。今回、記事を担当するにあたって眠っていたドラフトを改めて読んでみると、「たった1年でこれだけ変わるのか」とちょっとしみじみしました。
さすがに当時のままでは使えませんが、そのままにするのも惜しい記録です。
そしてCRE業務におけるAIとの関わり方がこの1年で劇的に変わった事もあり、そのドラフトは今の状況を比較するのに最適な「記録」となりました。
今回は1年前の2025年と、2026年現在での変化を比較してみたいと思います。
続きを読む
API 開発をしていると、こんな問題に直面することがあります。
これらの問題の根本原因は、ビジネスロジックが DB・外部 API などの具体的な実装に直接依存していることです。
この依存関係を切り離し、変更に強い設計にするためのアプローチが「依存性逆転の原則（DIP）」です。
依存性逆転の原則（DIP）を TypeScript で実装した例を紹介します。クラスや DI コンテナは使わず、関数パラメーターによる手動 DI というシンプルな方法で実現します。
続きを読む
