Kiro(kiro.dev)は、AWSが開発したIDE型のコーディングエージェントです。CursorやWindsurfのようなVS Codeフォークエディタに分類されます。現在はパブリックプレビュー中で、サインアップするとKiroでClaude Sonnet 3.7 とClaude 4 Sonnetを利用できます。 KiroThe AI IDE for prototype to productionKiroKiroの特徴は、スペック駆動開発、エージェントフック、ステアリングファイルといった独自の機能を通じて、ソフトウェア開発のライフサイクル全体を支援します。それぞれ見ていきましょう。 スペック (Specs)駆動開発Kiroの中核をなすのが「スペック＝仕様書」機能です。これは、ユーザーが入力した大まかな指示（例：「ユーザー認証機能を追加して」）をもとに、AIが「要件定義」「設計」「タスクリ

講習会用にまとめたもの。可能なら公式ドキュメントを参照するのを推奨するが、この資料ではサッと使いはじめるために要点を絞って解説する。 claude-code は claude-code 自身で開発されており、恐ろしい速度で更新されてる点に注意。この資料は一瞬で古くなる。 アカウントの契約等は省略 インストールと実行

この記事はほぼすべて Gemini CLI に書いてみてもらいました。ただし、ファクトチェック＆手修正済みです。もし間違えていたらこっそり教えてください。さいごにとおまけは人力です。 Gemini CLI チュートリアル tl;dr コマンドラインで対話的に使えるオープンソースのAIエージェント。 npx https://github.com/google-gemini/gemini-cli ですぐに利用開始。 @ でローカルファイルやディレクトリをAIのコンテキストに追加。 ! でシェルコマンドを直接実行、シェルモードへの切り替えも可能。 GEMINI.md ファイルでプロジェクト毎のカスタム指示をAIに記憶させる。 Google検索との連携、安全なサンドボックスでの実行、ツールの自作など高い拡張性。 1. はじめに Gemini CLI へようこそ！ このドキュメントは、Googleが

ティム・オライリーといえば、世界中のプログラマに信奉されているオライリー・メディアの創業者で、「Web 2.0」という言葉を広めたことでも知られる人物だ。 そのオライリー氏は、今年2月に、プログラミングが完全に新しい時代に入りつつあることを書いていた。同社のRadar Blogというページで読める「The End of Programming as We Know It」（私たちが知っているプログラミングの終焉）である。 オライリーの「Coding with AI: The End of Software Development as We Know It」の記事。映画『マトリックス』的ビジュアルもマッチしている。 5月8日には、同社のAI Codeconカンファレンスが、そのまま「Coding with AI: The End of Software Development as We

AI によるコーディングの支援はコード補完型からチャット型、そして自律型へと進化しています。この記事では現時点で主流となっているコーディングエージェントの種類とその特徴を整理したうえで、エンジニアの仕事の変化について考察します。 コーディングの仕事における AI 技術の関わりといえば、GitHub Copilot を代表するエディタ補完型が主たるものとして認識されてきました。補完型の AI はユーザーが途中まで書いたコードを補完する形で提案を行うことから、ペアプログラムの相方のような存在として捉えられていました。例えば function add と書き始めると、AI は (a: number, b: number): number { return a + b; } といった形で関数の定義を提案します。ユーザーは Tab キーを押すことで提案を受け入れたり、提案が気に入らなければそのままコ

これを記事にしている 2025 年 5 月の二年ほど前 (2023-06-02) に、縁あって明治大学 情報科学科での特別講義 [1] を担当させてもらいました。 身内の評判は悪くなかったのでスライドは公開していたんですが、単に Google Slides を公開状態にしただけだったんですね。 [2] これではあとから参照・引用するのも難しく、ちょっともったいないかと思ったので、いまさらながら記事の形でまとめなおしておくことにしました。 一年も経てば情報が古くなってしまうコの業界です。賞味期限切れの話もあると思いますが、話のネタにでもしてもらえれば幸いです。 講義の対象と目的 この講義、目的は2つあって、まず「最新の情報科学トピックに触れる」こと。 それから、就職活動が始まる3年生がメインの対象者なので、 今後のキャリアプランとか人生指針に関するいろいろな視点を持ってもらうことです。 この

Vibe Codingとは、AIに身を委ねて、バイブス、感覚でコーディングする手法のことだ。LLMの生成するコードを無条件に信じ、その積み重ねでソフトウェアを作る。理想的には、「こんなものを、いい感じで」とAIに頼むだけでコードができあがる、夢のノーコード開発環境のことを指すのだろう。 現実としては、そんな簡単にはいかない。AIは私たちの心を読む超能力者ではない。「いい感じ」と言っただけではAIはただ適当に振る舞う。まず実現したいことの明確なビジョンと、それを支えるしっかりした設計が必要になる。それをAIが理解できる言葉で、適切にタスク分解して伝えなければならない。今のところ、ただ要望を並べただけでまともなコードができあがることはまれだ。 Thoughtworksが行った実験が、この現実をよく示している。彼らは「システム更新プランナー」というアプリケーションをAIに作らせる実験を、３つのア

『Software Design 5月号』の第２特集「クラス設計の鉄則」を寄稿しました。 gihyo.jp 第２特集の概要と、今回はとりあげなかった、SOLID、GoFデザインパターン、凝集度と結合度について、私がどう捉えているかを説明します。 概要 第２特集のクラス設計の鉄則は３章で構成されています。概要は次の通りです。 第1章：クラス設計再入門 モジュール性・関心の分離・依存関係を意識する 第2章：迷わないクラス設計の指針 アプリケーション開発の実践例から考える現代的な設計方針 第3章：設計の落とし穴対策 コードから問題を検知する着眼点と改善方法 第１章：クラス設計再入門 この章は、クラス設計の基礎として、ソフトウェア設計の三つの視点を紹介しています。 ソフトウェアシステム構築の基本課題として「複雑さ」と「変更容易性」に焦点を合わせ、二つの課題に取り組むための考え方として、「モジュール

最近のAIの進化は目覚ましく、コーディングにおいても、もはや人間が一切を関知せず"ノリ"で全てを完成させるvibe codingなる概念まで登場しました。 しかし、現実の業務にこれを適用すると、まあ、上手くいきません。 1ファイルで完結するようなスクリプトであれば上手くいきます。驚くほど上手くいってびっくりします。テトリスを書いて、と指示したらテトリスは完成するでしょう。 しかし現実のコーディングは素朴なテトリスを実装するほど単純ではありません。 LLMの限界 ここで一つの問いを考えます。 「入社初日の知識豊富なエンジニア」と「ここ数ヶ月の間、機能Aの開発に携わっている普通のエンジニア」、どちらが5分で機能Aの開発を進められるか？ おそらく、答えは後者になると思います。 これがまさにAIによるコーディングに起こっていることで、 どれだけLLMの性能が向上したところで、実装に関する知識（コン

MCPサーバをつくって学ぶ 最近、AIアシスタントの文脈で「MCP」や「MCPサーバー」という用語を聞くようになった。 MCP（Model Cotext Protocol）とは？ Model Context Protocolとは、AIとアプリケーションとの間で情報を効率的にやり取りするためのプロトコル。 簡単に説明すると、AIが自分の作ったアプリケーションを操作できるように、データを提供したり、機能を公開したりして、扱いやすくするための方法を定義したもの（プロトコル）。 MCPを使うことで、AIがアプリケーションのコンテキストを理解できるようになる。 たとえば、いままで手動でデータを貼り付けたり、プロンプトを書いてコンテキストを補っていたりしたものが、AIが直接アプリケーションから取得できるようになる。 MCPサーバー 主に3つの機能を提供する。 Resources … クライアントが読み

Reactはシンプルなサイトから複雑なアプリケーションまで、非常に幅広く採用されている人気のフレームワークです。OSS化から10年以上の歴史がありながら、昨今もReact Server Componentsなど革新的なアイディアを我々に提案し続けています。 一方で、React Server Componentsへの批判的意見やBoomer Fetching問題などを見ていると、Reactチームと一部Reactユーザーの間には意見の相違が見て取れます。この意見の相違はそれぞれが置かれた状況の違いから生じるもの、つまり「見てる世界が違う」ことに起因してると筆者は感じています。 本稿では「Reactチームの見てる世界」を歴史的経緯を踏まえながら考察し、Reactの根本にある思想やコンセプトに対する読者の理解を深めることを目指します。 要約 ReactはMetaの大規模開発を支えるべく開発され、シ

コードレビューする時、自分がどんなことに気を付けているか (本当は気をつけたいか)みたいなポイントをまとめてみた。 コードレビューの目的 プロダクトの品質を担保するため 人は基本的にミスをするもの 1人で考えたものより、2人、3人集まって考えたものの方が良いことが多い 知識をチーム内でシェアするため チームでコードに関する知識を常に共有し続けることで、「この機能はAさんしか知らない」といった属人化問題を防ぐ Aさんが有休取った時に限って障害が起きたりするんですよね。分かります 他の人が書いたコードを読み、さらに分からないことは質問できる、素晴らしい学びの場だと捉える 責任をチーム内でシェアするため 何か問題が起きた時に関連するコードを書いた人間だけが責められるようなことは決してあってはならない レビュー時 (又はそのコードがデプロイされるまで)に問題に気づけなかったチーム全体の責任なので、

アーキテクチャを理解可能にするために、同時に見るべき関心事は最大7個にしよう、という話がよかった。 よくわからない難しいコンポーネントの話をしてると、「これってこういうこと？」「それは〇〇という概念があって…」というのが延々と続いて、話が全然進まない、ということがある。 そういうときは、抽象を見つけるのに失敗していて、フラットに様々な概念を並べてしまっている、と言える。 適切に意味をまとめていって、中心概念と、それの付随する概念が最大6個となるように、六角形の花、ヘックスフラワーにプロットしよう、というアイデア。で、そのフラワーの1セルを拡大すると、さらに、中心概念と付随する概念6個、というかたちで、入れ子にしていく。 ソフトウェアの分割統治っていうと新しい話ではないけど、フラットな20個の概念に分割されても、覚えてられない。 この本では人間が一度に覚えていられるマジカルナンバーを参照して

なぜ依存を注入するのか DIの原理・原則とパターン 著者: Steven van Deursen, Mark Seemann 訳者: 須田智之 表紙には.NETやC#の文字はないのですが、前の版は"Dependency Injection in .NET"で.NETを前提した本のようでした。 ただ、はじめにで 本書では、.NETとC#を用いて、依存注入に関する用語や指針を包括的に紹介し、描写しているのですが、本書の価値が.NETの外の世界にも届くことを望んでいます。 とありました。 RustのDIでなにか活かせる教えを期待して、読んでみました。 第1部 依存注入 (Dependency Injection: DI) の役割第1章 依存注入 (Dependency Injection: DI) の基本: 依存注入とは何なのか? なぜ使うのか? どのように使うのか?まず、保守容易性(maint

『手を動かしてわかるクリーンアーキテクチャ 』の第二章の冒頭に登場する話題に共感したので紹介。 従来の多層アーキテクチャでは、データベースを中心にアプリケーションの 開発が行なわれます。この場合、Web 層はドメイン層に依存し、ドメイン層は 永続化層、つまり、データベースに依存することになります。そうなると、す べてのものは永続化層上に構築されることになり、その結果、いくつかの要因 が絡まり合って、問題が起きやすくなります。 手を動かしてわかるクリーンアーキテクチャ　ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発 20p 手を動かしてわかるクリーンアーキテクチャ　ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発 作者:Tom Hombergs,須田 智之インプレスAmazon 著者によれば、機能開発をデータベース中心に設計すると、ドメイン層と永続化層の密結合が

先日こういうツイートが流れてきた。 Q:なぜ金融系では未だにCOBOLが使われるんですか？ A:お手元にExcelがありましたら任意のセルに「=4.8-4.7-0.1」って入れてみてください。— 遊撃部長F/S&RWAs (@fstora) 2024年6月6日 Q:なぜ金融系では未だにCOBOLが使われるんですか？ A:お手元にExcelがありましたら任意のセルに「=4.8-4.7-0.1」って入れてみてください。 普段我々がゴリゴリ馬車馬のように使っているソフトウェアでよく利用されている浮動小数点型、すなわちfloatやdoubleなどは特定の算術に弱いことが知られている。というかもうこの手の話題はあまりに拡散されてしまったので、なぜかネット民はみんな知っている基礎教養、三毛別羆事件とかデーモンコアみたいな感じになっている。 ちなみにこれはCOBOLかそうではないか、という軸が問題になっ

列挙型、JavaでいうならEnum型、使っていますか。使わないわけにいきませんよね。 でも、Enumを使っていたせいで辛い目にあったことありませんか。ないですか。それならきっともうすぐに辛い目にあうと思います。 Enumはすべてのプログラマに等しく辛みを与えてくれるからです。そんな辛みについて、ちょっと一緒に直視してみましょう。 エムスリーエンジニアリンググループ、Unit1（製薬企業向けプラットフォームチーム）三浦(@yuba@reax.work) [記事一覧 ]がお送りいたします、エムスリー Advent Calendar 2023の6日目です。 アプリケーションプログラミング上の辛み 1. 既存のif文が偶発的に意図しない方に倒れる 2. switch文に至っては「どちらでもない」で処理不発に アプリケーションプログラミング上の対策 1. 分岐条件をEnumに持たせる 2. swi

ログの出力場所 ログは、開発者や運用担当者が見つけやすい箇所に出力することを原則としましょう。ファイルに出力する場合は、logディレクトリなどを作成しておくことをお勧めします。基本的に、出力先は以下の4つが想定されます。 ・ファイルに出力する コンソール外で起動するアプリケーションに使用される方法です。 ・標準出力 コンソールから起動するアプリケーションで使用されます。途中経過などを出力するための出力方法です。 ・外部ログ管理ツールのファイルに出力 外部のログ管理ツールを用いることが可能な場合は、専用のログ記録場所に出力することを推奨しています。 ・外部システムへ出力 開発者・運用者の作業やコミュニケーションを円滑に行うために、Slackなどのチャットツールに出力するケースもあります。ただし、稼働率に注意する必要があり過度なログの出力は控えるようにしましょう。 基本的に、外部ログ管理システ

名前付けのガイドラインでは、アセンブリ、名前空間、型、メンバー、およびパラメーターなど、クラス ライブラリの構成要素に対して適切な識別子を選択するためのガイダンスを示します。 これらのガイドラインに従った識別子を選択すると、ライブラリの使いやすさが向上します。このため、ユーザーはライブラリを使用するために新しい一連の規則を習得する必要性を感じずに済みます。 開発者にとって一貫性のある環境を提供するには、パブリック クラスやプロテクト メソッドなど、公開される要素にこれらのガイドラインを適用する必要があります。 ただし、コード全体での一貫性を維持し保守性を向上させるには、これらの規則をコード全体で一貫して使用することを検討します。 Portions Copyright 2005 Microsoft Corporation. All rights reserved. Portions Copy