<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/">
    <channel>
        <title>nekolas</title>
        <link>https://nekolas.dev</link>
        <description>nekolas's tech blog</description>
        <lastBuildDate>Fri, 06 Jun 2025 10:01:17 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>https://github.com/jpmonette/feed</generator>
        <language>ja</language>
        <image>
            <title>nekolas</title>
            <url>https://nekolas.dev/favicon.png</url>
            <link>https://nekolas.dev</link>
        </image>
        <copyright>All rights reserved 2025, nekolas</copyright>
        <item>
            <title><![CDATA[AI時代のDevOpsを考察する]]></title>
            <link>https://nekolas.dev/posts/2025-06-06-ai-devops</link>
            <guid>https://nekolas.dev/posts/2025-06-06-ai-devops</guid>
            <pubDate>Fri, 06 Jun 2025 00:00:00 GMT</pubDate>
            <content:encoded><![CDATA[<h2>はじめに：私の DevOps 体験</h2>
<p>私はこれまでの過去の経験で、DevOps に非常に興味を持って取り組んできました。特に、DevOps を進めるにあたって「何から始めるべきか」という問いに対して、私は<strong>CI を先に作り始める</strong>ということを重視してきました。</p>
<p>なぜ CI からなのか。それは、CI の構築を後から行うことが非常に大変だからです。複雑に組み上げられたシステムから後付けで CI を作っても、正しく全てがテストされていることを保証することは難しくなります。だからこそ、まずは CI を作り、<strong>TDD（テスト駆動開発）で開発を行うこと</strong>が重要だと考えています。</p>
<h2>組織としての DevOps：理想と現実</h2>
<p>DevOps を CI から始めることは技術的な側面ですが、組織としての DevOps の考え方も私は大好きです。</p>
<p>もともとエンジニアは、自分の開発効率の改善などを自分で行うことが多かったと思います。しかし、それを<strong>組織全体で行うと組織が大きくスケールする</strong>可能性があります。昔から社内 LT 会などを実施することで、ナレッジを共有し開発効率をチームや組織単位で改善するような取り組みも増えてきました。</p>
<p>しかし、これらはボトムアップ的な動きであるため、組織としての仕組みとして DevOps を進めるにはまだ弱いと感じていました。</p>
<p>実際に、DevOps を組織として進める役回りになったことが少しだけありますが、なかなか直接的な生産性に寄与することが難しく、「これなら、各チームの CI を改善したほうがいいのでは？」と思ったこともありました。しかし、さすがにそれだけを行うことは難しく、非常に苦労した思い出があります。</p>
<p>ここに関しては、どうすればよかったのか今でも悩んでいます。</p>
<h2>AI 時代の DevOps をこう考える</h2>
<p>しかし、時代は変わりました。AI の進化により、<strong>CI の改善やテストの自動作成などが一瞬で終わる</strong>など、かなり開発体験が効率化されてきていると感じます。</p>
<p>AI を使うことによって、これまで苦労していた部分が大幅に改善されてきています。DevOps によって直接的な生産性の改善として、CI の改善やテストケース作成の自動化などの効率化が期待できますが、<strong>DevOps における運用者の効率アップ</strong>も期待できると感じています。</p>
<h2>運用者における AI の活用</h2>
<p>まず、DevOps において運用者がどういった作業をこれまでしてきたでしょうか。</p>
<p>運用者は、業務領域として以下のような作業を担ってきました：</p>
<ul>
<li>インフラの構築と管理</li>
<li>CI/CD パイプラインの構築・運用</li>
<li>障害対応</li>
<li>全般的な保守</li>
</ul>
<p>これらの作業は、非常に専門的な知識が必要であり、また、手作業で行うことが多かったため、時間と労力がかかるものでした。しかし、<strong>AI の進化により、これらの作業も効率化される可能性</strong>があります。</p>
<h2>考察：どのような AI の活用ができるか</h2>
<p>これまで、人間の手によって開発生産性の改善などエンジニアリングに関するものは、人の手では限界がありました。そのため、その改善はチームに留まることが多く、組織全体としてスケールすることが難しかったと思います。</p>
<p>しかし、AI の進化によって、<strong>プラットフォームエンジニアリング</strong>といった文脈などでも言われているように、DevOps を大規模に組織的に行うことが可能になってきていると感じます。</p>
<p>そのスケールが行える部分が、エンジニアの中でも特に<strong>運用エンジニアの部分</strong>ではないかと考えています。</p>
<h3>具体的な AI 活用シナリオ</h3>
<p>運用エンジニアは、稼働しているプロセスの監視や障害対応を行うにあたって、開発しているサービスに障害が発生する前からその問題に気づけるようにしたり、ソースコードや品質の問題を事前に検知することが求められます。</p>
<p>そのためには、開発エンジニアが Ops の観点でコードを書いていくことが求められます。そういったときに、<strong>Cursor ルールで、Ops の観点のコード規約を追加する</strong>などを行うことで、保守性の高いコードを書くことができるようになります。</p>
<p>また、<strong>CI 上に Ops の観点によってプロンプトが設定された AI Agent を組み込む</strong>ことで、CI の中で保守性の高いコードを書くことが可能です。</p>
<p>それにより運用エンジニア自身も AI Agent を活用し、<strong>人間の目では見つけることができなかった問題を事前に検知し、障害が起きる前から未然に防ぐ</strong>可能性が高くなっていると思います。</p>
<p>これまで、CI や監視ツールの進化によって、ある程度は補っていたものではありつつも、人間の目によって保守されてきた部分が、AI の進化によって、より効率的に行えるようになり、それが<strong>組織全体へのスケールが可能</strong>になってきていると感じています。</p>
<h2>まとめ</h2>
<p>DevOps の考えをこれまでは人間が守ってきましたが、チームではなく組織全体で守ることはスケールに限界がありました。</p>
<p>しかし、<strong>CI 上や監視ツールに AI Agent を組み込む</strong>ことで、人間では限界だった部分を AI が補完し、組織全体での DevOps の実践が可能になってきていると思います。</p>
<p>AI 時代の DevOps は、単なるツールの進化ではなく、<strong>組織のスケーラビリティを根本的に変える可能性</strong>を秘めています。これまで個人やチームレベルでしか実現できなかった改善が、AI の力によって組織全体に波及していく。これこそが、真の DevOps の姿なのかもしれません。</p>
<hr>
<p><em>この記事は、実際の DevOps 経験と AI 技術の進歩を踏まえた考察です。皆さんの組織ではどのような AI 活用をされていますか？ぜひご意見をお聞かせください。</em></p>
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[AI Agentの未来考察]]></title>
            <link>https://nekolas.dev/posts/2025-06-06-ai-future-consideration</link>
            <guid>https://nekolas.dev/posts/2025-06-06-ai-future-consideration</guid>
            <pubDate>Fri, 06 Jun 2025 00:00:00 GMT</pubDate>
            <content:encoded><![CDATA[<p>最近、AI Agent（AI エージェント）の急速な進化にかなり注目しています。</p>
<p>これまで長らく Github Copilot というツールを愛用してきましたが、AI エージェントという革新的な技術の登場により、私が知っているプログラミングの世界が根本的に変わろうとしていることを、日々実感しています。</p>
<p>今回の記事では、この変化について私なりの考察をお伝えします。</p>
<h2>Github Copilot から始まった AI 支援の世界</h2>
<p>まず最初に、私の AI 活用の歴史について少し話します。AI を活用したプログラミングツールとしては、かなり早い段階から Github Copilot を使っていました。</p>
<p>Github Copilot は、多くの開発者にとって既に馴染み深い存在だと思いますが、正式には「AI が支援するコーディングアシスタントツール」として位置づけられています。このツールの登場により、私のコーディング体験は確実に向上しました。</p>
<p>しかし、ここで一つ疑問が浮かんできます。そもそも「コーディングアシスタント」とは、具体的にはどのような存在なのでしょうか？</p>
<h2>コーディングアシスタントとは何か</h2>
<p>コーディングアシスタントとは、人工知能（AI）の力を借りて、私ソフトウェア開発者のプログラミング作業を様々な側面から支援してくれる、非常に心強いツールのことです。</p>
<p>具体的には、以下のような機能を提供してくれます：</p>
<ul>
<li><strong>コードの自動生成</strong>: 私の意図を理解して、適切なコードを自動的に作成</li>
<li><strong>コードの補完</strong>: 書きかけのコードを察知して、続きを提案</li>
<li><strong>バグの検出</strong>: 潜在的なエラーや問題点を事前に発見</li>
<li><strong>コードのリファクタリング</strong>: より良い構造への改善提案</li>
</ul>
<p>この中でも、特に日常的に恩恵を感じているのは「コードの自動補完・生成」機能です。この機能により、開発効率が飛躍的に向上したことは間違いありません。</p>
<h2>プログラミングスタイルの変化</h2>
<p>実は、ここ最近になって、私が行う「コードを書く」という行為そのものが、知らず知らずのうちに大きく変化してきました。</p>
<p>「AI エージェント」という言葉を聞いたことはありますか？一見すると、AI エージェントと AI コーディングアシスタントは非常に似ているように思えるのですが、実際に使ってみると、その違いは想像以上に大きいということが分かってきました。</p>
<h3>AI コーディングアシスタントの特徴</h3>
<p>まず、現在の多くの AI コーディングアシスタントについて整理してみましょう。これらのツールは、言うなれば「非常に優秀な指示待ちアシスタント」のような存在です：</p>
<ul>
<li><strong>受動的な姿勢</strong>: 常に私からの指示を待っている状態</li>
<li><strong>プロンプト駆動</strong>: 具体的なプロンプト（指示文）を書くことで初めて動き出す</li>
<li><strong>限定的な作業範囲</strong>: 一度に生成できるコード量には制限がある（概ね 100 行程度まで）</li>
<li><strong>単発的な支援</strong>: 一つの指示に対して一つの回答を提供</li>
</ul>
<p>もちろん、これでも十分に素晴らしい支援を受けることができるのですが、より大規模な開発作業を考えた時には、どうしても物足りなさを感じることがありました。</p>
<h3>AI エージェントの革新性</h3>
<p>一方で、AI エージェントは従来の AI コーディングアシスタントとは根本的に異なるアプローチを取っています：</p>
<ul>
<li><strong>能動的な姿勢</strong>: 指示待ちではなく、<strong>自ら積極的に次のステップを提案し、実行する存在</strong></li>
<li><strong>継続的な対話</strong>: 単に「コードを書いて終わり」ではなく、その後の展開も考えてくれる</li>
<li><strong>包括的な支援</strong>: 例えば「テストも書きましょうか？」「実際に動作確認してみますか？」といった提案をしてくれる</li>
<li><strong>プロアクティブな問題解決</strong>: 私が気づかない課題も先回りして解決してくれる</li>
</ul>
<p>この違いは、実際に体験してみると本当に驚くべきものがあります。</p>
<h2>AI エージェントは至れり尽くせり</h2>
<p>AI エージェントの最も印象的な特徴は、まるで経験豊富な人間の同僚のように振る舞ってくれることです。これにより、私開発者の負担は想像以上に軽減されることになります。</p>
<h3>従来の AI コーディングアシスタントの制約</h3>
<p>これまでの AI コーディングアシスタントを使う際には、以下のような配慮が必要でした：</p>
<ul>
<li><strong>明示的な指示が必要</strong>: どのファイルを編集したいのか、どの部分を変更したいのかを詳細に指定</li>
<li><strong>コンテキストの制限</strong>: AI が一度に理解できる情報量に限界があるため、複雑なプロジェクトでは作業範囲を細かく区切る必要がある</li>
<li><strong>継続性の欠如</strong>: 前回の作業内容を覚えていない場合が多い</li>
</ul>
<h3>AI エージェントの優位性</h3>
<p>これに対して、AI エージェントは以下のような革新をもたらしています：</p>
<ul>
<li><strong>実質的に無制限のコンテキスト理解</strong>: プロンプトのサイズを気にする必要がほとんどない</li>
<li><strong>深い理解力</strong>: 私が本当に何を実現したいのかを総合的に理解</li>
<li><strong>自動的な情報収集</strong>: 必要な情報を自ら収集し、整理してくれる</li>
<li><strong>最適解の提案</strong>: 収集した情報を基に、最も適切なソリューションを提案</li>
</ul>
<p>技術的な背景として、DeepResearch のような先進的な技術により、AI エージェントは複数のプロンプトを自発的に分割し、段階的に必要な情報を収集することができるようになっています。これにより、私開発者は複雑な指示の出し方を覚える必要がなく、自然な言葉で要望を伝えるだけで、大規模なコード生成が可能になりました。</p>
<p><strong>つまり、理論的には、たった一つの自然な指示だけで、完全なアプリケーションが完成してしまうことも夢ではないのです。</strong></p>
<h2>AI エージェントと CI/CD 環境の関係について</h2>
<p>ここで、私自身が少し勘違いしていた点について正直に話します。AI エージェントというと、Devin のような製品が有名ですが、私は当初、これらのツールは主に CI/CD パイプラインのようなバックエンド環境で動作し、「気がつくとアプリケーションが完成している」という魔法のような体験だけを提供するものだと思い込んでいました。</p>
<h3>実際の AI エージェントの多様性</h3>
<p>しかし、実際に調べてみると、AI エージェントの世界はもっと多様で身近なものでした：</p>
<ul>
<li><strong>エディタ統合型</strong>: 従来の AI コーディングアシスタントと同様に、私が普段使っているエディタに統合されているもの</li>
<li><strong>使い勝手の継続性</strong>: 慣れ親しんだインターフェースで、より高度な機能を利用できる</li>
<li><strong>段階的な移行</strong>: 既存のワークフローを大きく変えることなく、AI エージェントの恩恵を受けることができる</li>
</ul>
<p>そのため、一見しただけでは、AI エージェントと従来の AI コーディングアシスタントの違いが分からない場合も多々あります。</p>
<h2>AI エージェントを見分ける方法</h2>
<p>それでは、数多くある AI 支援ツールの中から、真の AI エージェントを見分けるにはどうすればよいでしょうか。公式サイトに「AI エージェント」と書かれていれば分かりやすいのですが、実際の機能面での違いを理解することが重要です。</p>
<h3>見分けるポイント</h3>
<h4>1. AI の人格化の度合い</h4>
<p>AI エージェント製品の多くは、AI を単なるツールとしてではなく、<strong>一人の有能な同僚のような存在として扱う傾向</strong>があります。製品の説明文や使用体験において、AI が主体的に行動する存在として描かれていることが多いです。</p>
<h4>2. モデル選択に関するアプローチの違い</h4>
<ul>
<li><strong>従来の AI コーディングアシスタント</strong>: 使用者が「GPT-4 を使いたい」「Claude-4o を使いたい」など、具体的な AI モデルを選択できることが一般的</li>
<li><strong>AI エージェント</strong>: モデルの選択権を使用者に委ねない、または複数のモデルを組み合わせて最適な結果を出すことに重点を置く</li>
</ul>
<h4>3. 自動最適化の思想</h4>
<p>AI エージェントの根底にあるのは、「AI 自身が最適な判断を行う」という思想です。そのため、私使用者はどのモデルを使用するかという技術的な詳細を気にする必要がありません。</p>
<p>AI エージェントは、AI の能力を最大限に引き出すために、私開発者が技術的な詳細を意識しなくても済むように、非常に慎重に設計されています。</p>
<h2>まとめ</h2>
<p>最後に、これからの時代を生きる私開発者への提案をします。</p>
<h3>AI エージェントを試してみよう</h3>
<p>まずは、ぜひ一度 AI エージェントを実際に体験してみることをお勧めします。</p>
<p>もしあなたの AI 活用の知識が Github Copilot 程度で止まっているとしたら、「AI エージェント」と銘打っている製品に少しの投資をして試してみることで、プログラミングの世界に対する認識が根本的に変わる可能性があります。</p>
<h3>プログラミングパラダイムの大転換</h3>
<p>私が直面している変化は、単なる技術的な進歩以上の意味を持っています。これは、プログラミングそのもののパラダイム転換と言えるでしょう：</p>
<ul>
<li><strong>従来</strong>: 私が一行一行、丁寧にコードを積み上げていく時代</li>
<li><strong>現在・未来</strong>: AI と自然な対話を通じて、アプリケーション全体を協力して構築していく時代</li>
</ul>
<h3>変化への適応</h3>
<p>この大きな変化の波に乗り遅れないためにも、今この瞬間から AI エージェントという新しい開発パートナーに慣れ親しんでおくことが、私開発者にとって非常に重要になってくるでしょう。</p>
<p>新しい技術への投資は時として不安を伴うものですが、この変化は避けて通れない未来の姿だと私は確信しています。ぜひ一緒に、この新しい時代のプログラミングを楽しんでいきましょう。</p>
<hr>
<p>最後まで読んでいただき、ありがとうございました。あなたの AI エージェント体験が、素晴らしいものになることを願っています。</p>
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Figmaの裏技 カーソルチャットに出る炎]]></title>
            <link>https://nekolas.dev/posts/2025-06-06-figma-cursor-chat-tips</link>
            <guid>https://nekolas.dev/posts/2025-06-06-figma-cursor-chat-tips</guid>
            <pubDate>Fri, 06 Jun 2025 00:00:00 GMT</pubDate>
            <content:encoded><![CDATA[<p>短めの記事になりますが、Figma のカーソルチャットでリアクションを出す裏技を紹介します。</p>
<p><a href="https://help.figma.com/hc/ja/articles/1500004290981-%E3%82%B9%E3%82%BF%E3%83%B3%E3%83%97-%E7%B5%B5%E6%96%87%E5%AD%97-%E3%83%8F%E3%82%A4%E3%82%BF%E3%83%83%E3%83%81">Figma のこちらの記事</a>では、リアクションを出す方法がありますが、実はこちらはカーソルチャットで出す方法があります。</p>
<h2>カーソルチャットとは？</h2>
<p>カーソルチャットは、Figma のリアルタイムコラボレーション機能の一部で、他のユーザーがどこにカーソルを置いているかを表示し、コメントやリアクションを共有できる機能です。<br>カーソルチャットを使うには、FigJam 上で、「/」を入力して、カーソルチャットを開始します。</p>
<p>吹き出しが表示されますので、そこにメッセージを入力することで吹き出しが表示され、他の人にその吹き出しが見えるようになります。</p>
<h2>カーソルチャットでリアクションを出す。</h2>
<p>カーソルチャットでリアクションを出すには、吹き出しの中に「fire」と入力します。すると、炎の絵文字が表示されます。</p>
<p>炎の他にも、様々なリアクションが用意されています。<br>例えば、<code>&lt;3</code> と入力するとハートの絵文字が表示されます。</p>
<h2>リアクションの一覧</h2>
<p>リアクションは以下のようなものがあります！</p>
<ul>
<li>lit: 吹き出しが赤くなるだけ</li>
<li>fire, dope, hot: 炎</li>
<li><code>&lt;3</code>: ハート</li>
<li>lol: 笑い</li>
<li>bye: バイバイ</li>
<li>whoa, omg: 驚き</li>
<li>bummer, noo: 不満</li>
<li>chill, swag: サングラス</li>
</ul>
<p>サングラスをかけた絵文字は、カーソルチャットの吹き出しの中でしか見ることができないので、裏技的な使い方になります。<br>自分が調べた中では、👀 のリアクションは見つけることができませんでした！</p>
<p>ぜひ活用してみてください！</p>
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[入社エントリを書きました]]></title>
            <link>https://nekolas.dev/posts/2025-04-18-entry</link>
            <guid>https://nekolas.dev/posts/2025-04-18-entry</guid>
            <pubDate>Fri, 18 Apr 2025 07:28:19 GMT</pubDate>
            <content:encoded><![CDATA[<p><a href="https://note.com/nekolas/n/n3622badda222">【入社エントリ】 Webプログラマーだった私がアプリケーション基盤を選んだワケ｜nekolas / Takahashi</a></p>
<p>入社エントリを書きました。
このエントリは、私がアプリケーション基盤を選んだ理由について書いています。
アプリケーション基盤エンジニアってなんだろうって方は読んでみてください！</p>
]]></content:encoded>
        </item>
    </channel>
</rss>