はてなブックマーク

クラシル株式会社で開発マネージャーをしているfunzinです。 AIがさまざまな業務で使えるようになった今も、気づくと自分で解決していることが多いかと思います。AIを使うことが「選択」である限り、「自分でやった方が早い」というバイアスには勝てません。 本記事では、「AIを使うことを選択ではなく動線に変える」　という観点で、AI活用習慣を作るために実践していることを紹介します。 なぜAI利用が定着しないのか コーディング補助やドキュメント作成といった場面では、AIがすでに当たり前のように使われています。しかし、「使える状態にした」と「毎日の仕事でAIが動線に入っている」の間には、思っている以上距離があります。 自分自身を振り返っても、AIツールが手元にあるのに従来の作業フローを変えにくいと感じる瞬間が何度もありました。急ぎのSlack投稿や簡単な調べ物は、AIを利用するより自分で手を動かした

はじめに こんにちは！「PayPayで！」バーコードリーダーを画面に直接押し当ててくるのは止めてください。たろう眼鏡です。 クラシル社でサーバサイドの開発をしています。 前回の記事ではKarpathy氏のautoresearchを紹介して、バックエンドのパフォーマンスチューニングに転用しました。今回もKarpathy氏です。もう完全にファンクラブです。 2026年4月、Karpathy氏がLLM WikiというGistを公開しました。ざっくり言うと、RAGのように毎回ドキュメントを検索して回答を生成するのではなく、LLMに永続的なWikiを書かせて知識を蓄積&整理&育成していくというアプローチです。Obsidianと組み合わせると、LLMによりWikiが整理された状態で閲覧&グラフで可視化できるので相性がいいです。 RAGとの違い、Claude Codeへの実装、自分で追加した設計判断の3

はじめに 初めまして、クラシル社でiOSアプリを開発しているエンジニアの王👑です。以後よろしくお願いします。 2025年2月、私はクラシル入社しました。SwiftUI + SPM マルチモジュール構成の大規模なコードベース。普通なら、まずコードを読み込み、アーキテクチャを把握し、既存パターンを学ぶところから始まるはずです。 しかし、このチームでは違いました。Claude Code による AI 駆動開発が、すでに開発プロセスの中心に組み込まれていたのです。 入社初日、最初のタスクに取り組んだとき、私は驚きました。コードベースの知識がほぼゼロの状態でも、要件を伝えるだけで AI が既存コードを調査し、プロジェクトのパターンに沿った変更案を提案してくれる。「新メンバーの立ち上がり」という概念そのものが変わる体験でした。 この記事では、この AI 駆動開発サイクルがどのように回っているのか、そ

はじめに こんにちは、クラシルでバックエンドエンジニアをしている hama です。 私は Obsidian の Daily Note を毎日の業務記録として使っています。TODO やミーティングの予定、読んだ記事のメモなどを1ページにまとめて、あとから振り返れるようにしていました。 ただ正直なところ、私の場合、手で書いていた頃は手間が多く、Daily Note をしっかり書き残さない日も多く内容が常に充実しているとは言えませんでした。 そこで、Claude Code のスキル機能を使って Daily Note への記録の下準備を自動化しました。 TODO や Meeting の自動挿入だけでなく、Slack・GitHub・Notion のログからその日のサマリを AI に生成させることで、手作業では続かなかった日次の振り返りが毎日回るようになりました。 さらに、Daily Note を元に

はじめに こんにちは、クラシルでバックエンド開発をしているmighteeです。 社内では開発者だけでなくbizメンバーも含めてAI活用を積極的に進めています。開発メンバーはすでにAIを日常的に使いこなしていますが、その中で新しい課題も見えてきました。 Claude Codeを使って、Railsアプリケーションで2つの新機能の要件定義からリリースまでを担当しました。期間は約3週間です。開発はスクラム単位で進めていて、実装は自分がClaude Codeと一緒に進め、レビューは別スクラムのバックエンドエンジニアに見てもらう体制です。 個人の体感では、生産性は上がりました。マイグレーション、CRUD、Rakeタスクといった定型コードはAIが初稿を書いてくれるので、設計判断に集中する時間が増えました。ところが、チーム全体で見ると別の景色が見えてきます。特に、実装の文脈を共有していないレビュアーにとっ

たとえばある施策では、実装を5つのPhaseに分割し、Phase 1-1でAPI層、Phase 1-2でタブの動的追加、Phase 2でコンテンツ画面……と段階的に進めていく計画を立てました。各Phaseには新規作成ファイルと既存ファイルの編集一覧も含まれ、/execute-plan に渡すとPhase単位で実装が進みます。 Claude Codeのスキルで開発フローを自動化 これらのドキュメントをAIに効率的に渡すために、Claude Codeのカスタムスキルを3つ作りました。 /create-spec — AIが質問・提案を主導しながら要求仕様書を段階的に作成 /create-plan — 要求仕様書をインプットに、AIが実装計画を提案 /execute-plan — 計画書に基づいてPhase単位で実装を実行 実際の開発フローは以下のようになります。 /create-spec で要求

はじめに クラシルで Android エンジニアをしている go です。 「Figma の URL を渡すだけで Compose UI を実装できたら最高だな」と思い、Figma MCP Server を使った PoC 検証を行いました。結果として Figma MCP は強力ですが、そのままではプロジェクト固有のデザインシステム（以下 KurashiruTheme）に準拠したコードが生成されないという課題に直面しました。 Figma MCP の出力と Android のデザインシステムをマッピングする Claude Code ルールを作成することで、Figma → KurashiruTheme 準拠の Compose コードの自動生成を実現した経緯を紹介します。 課題: Figma MCP の出力をそのまま使うとデザインシステムに従ったコードが生成されない ここでいう「デザインシステムに従

はじめに こんにちは、クラシルでバックエンドエンジニアをしている hama です。 AIエージェントの進化により、私自身の開発スタイルが変わり、AIエージェントとの対話が開発プロセスの大部分を占めるようになりました。 こうした変化のなかで、VSCode から WezTerm + Neovim に移行しました。本記事では、AIエージェント（主に Claude Code）を中心に据えたターミナル構成と、日々の開発で使っている工夫を紹介します。 なぜ VSCode を離れたのか もともと VSCode を使って開発していました。ただ、マルチリポジトリ構成のサービスを扱っているため、リポジトリごとに VSCode のウィンドウを開く必要があり、常にいくつものウィンドウが散乱している状態でした。 そこに Claude Code をはじめとする AIエージェントが大きく進化し、ほとんどの作業が AIエ

はじめに こんにちは！3月よりクラシル社に入社しました、SREの moikei です！ クラシルに入社して驚いたのは、エンジニアだけでなくビジネスサイドのメンバーもClaude Codeを活用しており、AI活用が組織に浸透していることでした。 しかし、コードを書く速度が上がった分、CIに時間がかかっていると開発のリズムが止まってしまいます。あるプロジェクトではCIに20分かかっており、これがボトルネックになっていました。 入社後の最初のタスクとして、このCI改善に取り組みました。Claude Codeを活用してボトルネックの分析と改善計画の立案を行い、CIを20分から7分に短縮できました。 本記事ではその内容を紹介します！ CI構成の全体像 GitHub Actionsのself-hosted runnerからAWS CodeBuildを呼び出し、CodeBuild上でRSpecを実行する

TL;DR ユーザーさんの60日分の行動タイムラインから、インタビュー質問を自動生成している Circlebackの議事録をClaude Codeに取り込み、仮説検証マトリクスとしてinsights.mdに構造化 複数名のインタビュー結果をfindings.mdに統合するところまで自動化し、手動のレポーティング工数はほぼゼロになった はじめに レシチャレ プロダクトマネージャーのshioriです。 先日、CPOの坪田がClaude Code × GitHubでプロダクトマネジメントを再設計した話で、PdMワークを1つのGitリポジトリに集約する仕組みを紹介しました。 今回は、その仕組みの上で「ユーザーさんの定性インサイトがチームの共通資産になるまで」の自動化にフォーカスします。 候補者選定: 仮説は人間、抽出はClaude インタビュー候補者の選定には、人間の判断とClaudeの実行を明確

こんにちは、クラシルのラクです。 2026年3月だけで、サプライチェーン攻撃が立て続けに発生しています。 3月19日: セキュリティスキャナTrivyのGitHub Actionsが侵害され、CIで実行するだけでSSH鍵やクラウドトークンが窃取される状態に 3月24日: Trivyの侵害を起点にPyPIのLiteLLMにも波及。数時間にわたり悪意あるバージョンが配布 3月31日（本日）: npmのaxiosのメンテナアカウントが乗っ取られ、RATが仕込まれたバージョンが公開 Trivy → LiteLLMのように、1つの侵害が連鎖的に別のプロジェクトに波及するケースも出てきています。もはや「自分のプロジェクトは大丈夫」とは言えない状況です。 一方で、こうした攻撃の多くはパッケージマネージャの設定ひとつで防げる可能性があります。Andrew Nesbittが「Package Managers

はじめに こんにちは、AIにレビューを任せてたらいつしか自分がレビュー対象になっていました。たろう眼鏡です。 Karpathy氏が公開した autoresearch をご存知でしょうか。AIエージェントにLLMの訓練コードを渡して放置すると、勝手にモデルを改善し続けてくれるというリポジトリです。 これを見たとき、「この仕組み、サーバーサイドのパフォーマンスチューニングにも使えるのでは？」と思いました。コントローラーが遅い → コードを直す → ベンチマークを取る → 良くなったら採用、ダメなら戻す。これは日常的にやっている作業ですが、1塁ベースに全力でヘッドスライディングするような泥臭いものです。 1塁にヘッドスライディングするのはAIに任せて10分ごとに自動で回させたら、寝ている間に数十回の改善サイクルが走ります。ただし、AIに自律的にコードを触らせるには「暴走しない仕組み」が必要です。

はじめに クラシルで開発マネージャーをしているfunzinです。 本記事では、Claude Codeのスケジューラー機能を使って定常業務を自動化し、タスクを覚えておくストレスをゼロに近づける運用フローを紹介します。EM・PM・データ分析担当者など、定常作業を抱えるすべての方を対象にしています。Desktop スケジューラーで自動化を育て、安定したらCloud スケジューラーに昇格させるアプローチが実用的だったので、その運用方法を共有します 導入の背景 毎日こなす定常作業が、以下のように存在していました。 1on1の事前準備: メンバーのSlack・Notion・GitHubの活動を収集し、1on1で話す内容や成果と改善点を整理する チーム朝会: 朝会で出たアクションアイテムをTODOとしてSlackに投稿 議事録生成: MTG後に議事録を作成し、Notionに格納。Slackに要約を投稿

こんにちは、クラシルでデータエンジニアをしているharry(@gappy50)です。 突然ですが、私はAIで自分の仕事をほぼ無くしました。 人間の皆様、今までありがとうございました！ 冗談(でもないですが)はさておき、先に結論をお伝えします。まだ道半ばの部分もありますが、データマネジメントを正しくやってAI Readyな状態にしておけば、Snowflake Managed MCP Server × Claude Codeで開発・分析・マネジメントをAgenticに回せる手応えを得ています。 これは「リードタイムが短くなった」という改善の話ではありません。AIエージェントがデータの意味を理解した上で分析・開発・マネジメントを横断的に行うことが、データマネジメントの積み重ねによって初めて可能になったというゲームチェンジの話です。逆に言えば、AI ReadyでないデータにどれだけAIツールを適用

こんにちは、クラシルでデータエンジニアをしているharry(@gappy50)です。 我々データチームでは、昨年Tier定義の記事で紹介した通り、データモデルにTier（用途と重要度に応じた品質格付け。Tier3以上をAI利用可能とする）を設定し、品質を段階的に上げていく仕組みを運用しています。 Tierが上がるほどデータの信頼性が高まり、AIを含めた高度な活用が可能になる。この仕組み自体は順調に回り始めていますが、Tierを上げるプロセス自体がボトルネックになるという新たな課題に直面しました。 その中で、私たちのデータチームではClaude Code Agent Teamを使って、データの品質向上と分析のアジリティを両立させる取り組みを進めています。 目指すのは「AI Readyなデータ活用を組織全員で自走し続けられる状態」です。 本記事では、このボトルネックをClaude Code A

はじめに みなさん、スロットをご存知でしょうか？ 競馬、パチンコとくればもちろんスロットですが、Jetpack ComposeにもSlot APIというものがあります。 知られていたり知られていなかったりするので、今回はそれを紹介していこうと思います。 この記事の対象読者 Androidアプリ開発をしている人 UIの共通化設計に興味がある人 スロットとは まずは公式の「Slot-based layouts」の解説を見てみましょう Compose provides a large variety of composables based on Material Design with the androidx.compose.material:material dependency (included when creating a Compose project in Android St

はじめに こんにちは！クラシルリワードでバックエンド開発をしているkorosukeです。 今回は、Claude Codeを活用してアフィリエイト仕様書の自動更新システムを構築し、運用チームの問い合わせ対応時間を25%削減した事例をご紹介します。 カスタムコマンドでgit履歴から変更を検出し、Notion MCPで仕様書を自動更新する仕組みにより、手動作業を大幅に削減することができました。 背景：複雑化するアフィリエイト仕様と問い合わせの増加 クラシルリワードでは、多数のASP（アフィリエイトサービスプロバイダー）と連携し、複雑な成果通知システムを運用しています。 仕様が複雑で把握が困難な上、仕様書がない・古い状態のものもあり、毎回コード調査が必要となり問い合わせ対応時間が膨らんでいました。 抱えていた課題 仕様が複雑化していて、そもそも仕様理解が難しい：多数のASPとの連携により、パラメー

この記事は2025年9月16日時点の情報です。 OpenAI以外のプロバイダー・モデルの使用は考慮していません。 こんにちは、ラクです！ 最近、開発者の間でOpenAIの「Codex CLI」が話題になっていますね。 Codex CLIは今年の4月に公開されたばかりの歴史の浅いツールですが、短いサイクルで改善・アップデートが続いています。 現時点ではClaude Codeに比べて未実装の機能もありますが、その差は急速に縮まりつつあります。 ただし公式ドキュメントのようなものはなく、現時点ではリポジトリを直接見に行くしかありません。 本記事ではリリースノートやPRを読んで、私が実際に使って便利に感じた設定や機能を紹介していきます。 なぜ今、Codex CLIが話題なのか？ ChatGPTのサブスクリプションで利用できるようになった GPT-5の公開（2025年8月7日）以降、ChatGPTの

現在、すべてのデータモデルに対してTierを設定しています。 Lightdashで直接SQLを書いて作るチャートはTier5として扱います。 そこから、dbtでモデル管理しセマンティックを定義した状態がTier4、 最低限のテストとビジネスメタデータをすべて埋めたものがTier3と、 データモデルとメタデータの品質が高くなるにつれてTierが上がっていきます。 それらの品質がTier3まで上がってきたタイミングでAIエージェントを利用した分析を可能にすることを現時点では想定しています。 また、Tier4以下のデータモデルについては一定期間で自動削除をする実装もしており、アジリティを確保する一方で、定常的に見る必要があるデータは品質を高めることで、より高い品質と利便性を実現できることを目指しています。 このTier表で実現したいことは、AI活用のインセンティブをもたせつつ、アジリティと品質の

クラシルでサーバーサイドエンジニアをしている negi です。 Notion AI や Notion MCP を活用することで、より効率的な開発フローが実現できそうだったため、その取り組み内容を紹介します。 まずは、クラシルにおける仕様書の管理方法について触れておきます。 仕様書管理 仕様書の管理方法には、大きく分けて「ストック型」と「フロー型」の2つがあります。 ストック型は、1つの仕様書を最新の状態に保ち続ける方法です。 要件変更や設計変更があった際にも、同じドキュメントを更新していき、常に最新の状態を保つことを目指します。 一方、フロー型は、変更や追加のたびに新しい仕様書（ドキュメント）を作成していく方法です。 過去の仕様書は変更することはなく、履歴や経緯をドキュメントとして積み重ねていくことが特徴です。 クラシルでは、仕様書の運用において「フロー型」のスタイルを採用しています。 ユ

こんにちは。バックエンドエンジニアの松嶋です。 昨今、AIの進化のスピードが凄まじく、この波についていけているのか不安に感じている今日この頃です。 普段はバックエンド開発とSREを兼務していますが、個人的にはDevinを頻繁に活用しています。これにより、トイルのような面倒で反復的な運用タスクを任せられるようになり、大きな恩恵を受けていると実感しています。 ところで弊社では、昨年からAWS Bedrockを本格的に導入・運用しているのですが、今年のAWS Summit 2025で 「AWS で生成 AI アプリケーションを構築する時に役立つサービスと組み立て方を学ぼう」 というセッションの活用事例として取り上げていただきました！（やったね） この記事では、上記のセッションで紹介された内容に加えて、弊社がAWS Bedrockをどのように活用し、プロダクトの改善につなげているのかについて詳しく

はじめに こんにちは、iOS エンジニアの kaikai です。 プルリクエスト（PR）のレビューが滞ると、開発速度も品質も下がりがちです。 そこで私は AI エディタ「Cursor」 を “補助輪” として取り入れ、レビュー時間を短縮しつつ見落としを減らす 方法を実践しています。 本記事では、「AI に丸投げせず、人が主役のままラクにする」具体的な流れを紹介します。 前準備 1. レビュー専用のディレクトリを準備する まずは レビュー専用ディレクトリ をcloneしてきましょう。実装用ブランチと混ざらないので安心です。 私はレビュー依頼が頻繁に来るプロジェクトを Cursor で常に開きっぱなしにしています。 2. 拡張機能を導入する Cursor に GitHub Pull Requests and Issues 拡張機能 をインストールします。 この拡張機能によって、自分宛に来ている

🤖 はじめに こんにちは、haruto🐒（@ha_ru823）です。 今回は、これまでhtml/cssの触りくらいまでしか通ってこなかったエンジニアリング側への知識が浅いデザイナーの私が、v0・Figma・Cursor・ChatGPTを活用して、UI生成からデプロイまでを体験したプロセスをご紹介しようと思います。 今回はサンプルとして、ローカルに用意した4つの質問にそれぞれカテゴリ（気分）を割り当てて、ユーザーが選んだ回答の中で最も多かったカテゴリを診断結果として表示し、それに応じたおすすめコンテンツを紹介するシンプルな機能を作成してみました。 ▼ ぜひ診断してみてください！（曲はある程度自分のおすすめとかを入れています） 🤖 前提 前提として、今回の内容は実際の現場でサービス開発に組み込んでこんな取り組みができるよというよりも、AIを使って仕様作成→デプロイまでの道のりを体験してみ

こんにちは。dely株式会社のiOSエンジニア uetyo です！ この記事では、XcodeCloudの実行時間改善をAIと協業した結果、爆速で成果が出たので改善内容とAIの活用方法について紹介します 🤖 課題の整理 クラシルリワードのiOSアプリ開発では、XcodeCloudを使ったCI/CD環境を構築しています。 プロジェクトはSwift Package Managerによるマルチモジュール構成で、各モジュールごとにテストターゲットも分割しています（詳細）。 以前の改善でXcodeCloudのテスト実行時間を24分→19分まで短縮しましたが、機能追加やテスト拡充により平均実行時間が34分まで悪化してしまいました。 直近の開発メンバー増加に伴い、CIの待ち時間が開発効率の大きなボトルネックとして顕在化する中、実行時間短縮が急務となっていたため、再度の改善に取り組みました。 XcodeC

GitHub CopilotなどAI周りは頻繁に更新されているため、2025年4月時点での情報として参照してください。 はじめに GitHub Copilotはここ1,2ヶ月の間で多くアップデートが重ねられ、AI周りで先行するCursorやWindsurfとの差をかなり縮めてきています。デフォルトの設定でも十分便利に使えますが、設定や強力なプレビュー機能を活用することでさらに開発効率を向上できます。 また、この記事では、多くのプレビュー機能についても触れています。 先日、GitHub公式から明示的にプレビュー機能であっても学習に使われないことが発表されました。プレビュー機能にはワクワクする機能が多いのでぜひこの機会に利用してみてください GitHub CopilotなどGitHub製品のパブリックプレビュー版またはプライベートプレビュー版など、一般提供（GA）開始前の機能を利用していても、

はじめに 本記事では、Devinがdelyの開発現場にもたらした変化を実例を元に紹介します。 Devin 導入の背景 AI 活用で dely 全体の生産性を底上げしたい 人がやること／AI に任せることを切り分け、ムダな工数を削減 Devin で解決したかった課題 権限変更リクエスト急増によるエンジニア工数の肥大 ドキュメント陳腐化で最新情報が追いづらい 機能仕様の質問がエンジニアに集中しボトルネック化 以降のセクションで、Devin がこれらの課題をどう解決したかを説明していきます。 1. 非エンジニアからの依頼対応の工数削減 delyではTerraformを用いてGitHub、AWS、GCPの権限管理をIaC（Infrastructure as Code）として運用しています。従来、権限変更のリクエストはエンジニアがPRを作成して都度対応していました。しかし、非エンジニアからのリクエス

Halo、毎日ニコニコしているニコです。 データエンジニアとして、今delyでデータに関するいろいろな楽しいことをしています。 日本語は自分の母語ではないのにガタガタ書いてみましたw! 日本語でブログを書くのは少し難しいですが、もっと上達したいため、今回挑戦しようと思っています！ それでは、早速今日のトピックに入りましょう。Let's get started 👍 はじめに 最近、私たちはすべてのproductを一つのデータ集権化platformに統合しようと多くの計画を立てています。 なぜ私たちがすべてのproductを一つのデータ中央集権化platformに統合したいのかというと、この統合によって統一されたガバナンスを実現し、セキュリティを維持することができると信じているからです。また、これにより、今まで異なるデータ基盤やワークフローで分かれていたチーム間のsiloを解消することができ