https://example.org/Recent content on ishikawa's blogHugojaSat, 18 Apr 2026 10:00:00 +0900https://example.org/posts/first/Sat, 18 Apr 2026 10:00:00 +0900https://example.org/posts/first/<h2 id="何か作りたくて個人ブログを作った話">何か作りたくて個人ブログを作った話</h2> <p>暇な土日ですが、OSS活動は今日はいいかなって思って何をするか考えていたらブログを作ればいいんじゃないかと考えに至りました。</p> <p>ZennやQiitaなどのプラットフォームで投稿していましたが、つよつよエンジニア達はこぞってブログから情報を発信していたので、なんか真似したくなったってわけ</p> <p>じゃあどうやってブログ作ろかなーとOpusと話して、爆速でデプロイできる構成にしようと考えていたがあれやこれやしていく過程で違う構成になった。</p> <table> <thead> <tr> <th></th> <th>当初の想定</th> <th>実際の構成</th> </tr> </thead> <tbody> <tr> <td>SSG</td> <td>Hugo</td> <td>Hugo</td> </tr> <tr> <td>テーマ</td> <td>PaperMod</td> <td>PaperMod(RSS/404/robots.tstのみ現存)</td> </tr> <tr> <td>レイアウト</td> <td>PaperModの標準</td> <td>自作(index/single/list/terms)</td> </tr> <tr> <td>スタイル</td> <td>PaperModCSS</td> <td>自作</td> </tr> <tr> <td>グラフ</td> <td>なし(想定してない)</td> <td>　D3.jsでforce-directedグラフ　</td> </tr> <tr> <td>テーマ切り替え</td> <td>　PaperMod　</td> <td>自作</td> </tr> <tr> <td>ローカル開発</td> <td>Docker</td> <td>Docker</td> </tr> <tr> <td>デプロイ</td> <td>Cloudflare Workers</td> <td>Cloudflare Workers</td> </tr> </tbody> </table> <p>大体変わった。個人開発だし欲は出していこう。</p> <p>大体7:3くらいでCladueへ任せて、こちらはハーネスを握りながら開発していったつもり。</p> <p>個人的にはいい感じのブログができたのでZennやQiitaの記事も持ってきてブログを充実させよう！</p>https://example.org/posts/20260418/Sat, 18 Apr 2026 09:00:00 +0900https://example.org/posts/20260418/<h2 id="はじめに">はじめに</h2> <p>こんにちは。 2025年中盤からClaude Codeやcopilot等のエージェントツールが目まぐるしく進化し、コーディング作業はかなり楽になりました。 一方で、AI漬けの日々に疲れを感じることも増えてきて、休日くらいはAIデトックスして純粋にプログラミングを楽しんだほうがいいんじゃないかと思っています。</p> <p>この記事では、AIエージェントに開発の舵を渡してしまっていた自分が、ペアプロをきっかけに「自分の意思で設計する」ことを取り戻した話を書きます。</p> <h2 id="aiに任せていた頃">AIに任せていた頃</h2> <p>エージェントってどういう使い方されてます？</p> <p>私はというと、フレームワークのベストプラクティスをなんとなく拾ってきて読み込ませ、AI側にコーディングの規約や構造を判断させてレビューや開発をしていました。レガシー環境のプロジェクトでは、読み込ませる工程すら省いていたと思います。</p> <p>自分でレビューや調整はしていたので、大きく意図と違う状態になることは<strong>あまり</strong>ありませんでした。でも「なんか違う・・・」と感じたことは何回もあって、その度に<strong>まぁこんなもんやろ</strong>とAIの評価をしていました。</p> <p>今思えば、「自分はこう作りたい」が無い状態でAIに書かせていたので、出力の良し悪しを判断する基準がそもそも無かったんですよね。</p> <h2 id="転機--ペアプロで突きつけられたこと">転機 ― ペアプロで突きつけられたこと</h2> <p>AIに対する評価が180度変わったのは、0→1開発にアサインされた時のことでした。</p> <p>バックエンド開発が主な内容で、私ともう一人の開発メンバー、そしてメンター兼レビュワーとして2人の先輩エンジニアという体制で進めていました。0→1開発の経験が浅く、開発期限にも余裕がなかったため、「設計思想は作りながら確立して、まずは動くものを」をベースに開発を進めていきました。</p> <p>暫くして、歴が倍以上ある先輩エンジニアのTさんからペアプロの提案がありました。 正直、開発は進んでいるしスケジュールに間に合わせたい。悠長にリファクタリングしている暇は無い、と思っていました。</p> <p>しかし、そもそもTさんの思考や技術を盗みたいと思ったからこのチームへの移籍願いを出したのだと思い出し、ペアプロを受けることにしました。</p> <h3 id="このコードどんな意思があって書いた">「このコード、どんな意思があって書いた？」</h3> <p>ペアプロでTさんによく言われたのはこういうことでした。</p> <ul> <li>「このコードはどんな意思があって書いているのか」</li> <li>「どんなことがしたくてこの分け方にした？」</li> </ul> <p>たとえば、あるAPIからのレスポンス変換処理をServiceクラスに書いていた時、「なんでここに置いたの？」と聞かれました。正直、明確な理由はなく「なんとなくServiceだから」としか答えられませんでした。</p> <p>振り返ると、今まで自分がやっていたのは、バグが起こっていないか、先方から言われた仕様通りに動いているか、それだけでした。思想や自分の考えは基本無視して、どれだけIssueをこなすかだけを考えていた。そしてそれが評価に直結していたため、PRが通る＝これでいいんだという感覚になり、<strong>「なぜこう書くのか」を考えるという当たり前のことを、いつの間にか忘れていました。</strong></p> <h2 id="思想を整理する--設計ドキュメントを書いた">思想を整理する ― 設計ドキュメントを書いた</h2> <p>ペアプロを経て、私は現在のアーキテクチャ構造を選定した理由を細かい粒度で説明できるようにしようと決めました。各設計判断のメリット・デメリットとプロジェクトのドメインロジックから、設計のテーマを整理してTさんにも確認していただきながらドキュメントに落とし込みました。</p> <h3 id="なぜmvcでもクリーンアーキテクチャでもないのか">なぜMVCでもクリーンアーキテクチャでもないのか</h3> <p>最初に向き合ったのは「なぜこの構造なのか」という問いでした。</p> <ul> <li><strong>MVC</strong>：Modelに処理が集中しやすく、改修が重なると肥大化して保守が難しくなる</li> <li><strong>クリーンアーキテクチャ等</strong>：Interfaceやドメイン層の分離が必要で、今回の改修規模に対して過剰</li> </ul> <p>どちらも「ダメ」ではなく、<strong>このプロジェクトには合わない</strong>という判断です。そこで、Modelの責務をUsecase／Serviceの2層に分離する方針を採用しました。</p> <pre tabindex="0"><code>プレゼンテーション層 → ユースケース層 → サービス層 </code></pre><ul> <li><strong>ユースケース層</strong>：サービスを呼び出して業務フローを組み立てる（処理の流れだけを書く）</li> <li><strong>サービス層</strong>：具体的な処理を実装する</li> </ul> <p>この構造なら、今後ビジネスロジックが複雑化してもユースケース層は「サービスの呼び出し順序」だけを管理するので、コードがシンプルに保たれます。新しい処理はサービス層に追加し、ユースケース層で差し替えるだけ。改修時のバグリスクも抑えられます。</p> <h3 id="迷ったポイントサービス間のdiを禁止した理由">迷ったポイント：サービス間のDIを禁止した理由</h3> <p>設計を整理する中で特に迷ったのは、サービス同士の依存をどうするかでした。</p> <p>ServiceAからServiceBを呼びたい場面は当然出てきます。でも、それを許可するとサービス間の依存関係がスパゲッティ化して、どこで何が呼ばれているか追えなくなる。結局「サービスはサービスをコンストラクタで受け取らない（サービス間のDI禁止）」というルールにしました。</p> <p>サービス間で処理を共有したい場合は、ユースケース層で両方のサービスを呼び出して組み立てる。こうすれば処理の流れはユースケース層を見れば全て分かります。</p> <h3 id="メソッドの分類ルール">メソッドの分類ルール</h3> <p>サービス層のメソッドは以下の3種類に分類するルールも定めました。</p> <ul> <li><strong>更新系</strong>：状態を変更する。戻り値はvoid（値を返すべきではない）</li> <li><strong>参照系</strong>：副作用を持たない。DTOを受け取ってDTOを返す</li> <li><strong>ドメインロジック系</strong>：純粋関数として実装し、DTOの変換に特化させる（DB操作や外部サービス連携は行わない）</li> </ul> <p>この分類があると、メソッドを見た瞬間に「これは何をする処理か」が分かります。レビューする側も楽になりますし、AIにレビューさせる時も判断基準が明確になります。</p> <p>:::details 当時作成した設計ドキュメントの全文</p> <h2 id="各層の責務">各層の責務</h2> <h3 id="プレゼンテーション層">プレゼンテーション層</h3> <ul> <li>ユーザーインターフェースの処理</li> <li>HTTPリクエストの受け取りとHTTPレスポンスの返却</li> <li>コマンド引数の受け取りとコマンドの実行</li> <li>入力のデータ形式をバリデーション</li> <li>ユースケースの呼び出し</li> </ul> <h3 id="ユースケース層">ユースケース層</h3> <ul> <li>手続き的な処理の流れを記述する</li> <li>サービス層のメソッドを呼び出して処理を組み立てる</li> <li>ビジネスロジックはサービス層に委譲し、ユースケース自身には書かない</li> <li>コンストラクタでサービスを受け取る（DIコンテナ経由）</li> <li>サービス層からの例外を受け取らず、ユースケース内で例外処理を行わない（例外はプレゼンテーション層に伝播させる）</li> </ul> <h3 id="サービス層">サービス層</h3> <ul> <li>ドメインロジックとデータアクセスを一つの層で担当</li> <li>バリデーション・ビジネスルール・DB操作・外部サービス連携をすべてここに実装</li> <li>サービスはサービスをコンストラクタで受け取らない（サービス間のDI禁止）</li> <li>不正な状態は例外を投げる</li> </ul> <h2 id="主要なコンポーネント">主要なコンポーネント</h2> <h3 id="dto">DTO</h3> <ul> <li>層をまたぐデータ転送に使用</li> <li><code>readonly class</code> で実装する</li> <li>プロパティはプリミティブ型（Carbon等の標準ライブラリ型はプリミティブ型に詰め替える）</li> <li>ユースケースやサービスの引数・戻り値に使用</li> </ul> <h2 id="依存性の管理">依存性の管理</h2> <ul> <li>LaravelのDIコンテナ（AppServiceProvider.php）はサービスをユースケースに注入する目的のみで使用</li> <li>サービス同士はDIコンテナで結びつけない</li> </ul> <h2 id="コーディング規約">コーディング規約</h2> <h3 id="層の責務">層の責務</h3> <ul> <li>各層の責務を明確に分離する</li> <li>ドメインロジックはサービス層に書く</li> <li>ユースケース層にビジネスロジックを書かない</li> <li>サービスはコンストラクタで他のサービスを受け取らない</li> </ul> <h3 id="サービス">サービス</h3> <ul> <li>サービスのメソッドは単一の責務を持つようにする</li> <li>サービスのメソッドの役割は更新系・参照系・ドメインロジック系のいずれかに分類できるようにする</li> <li>更新系のメソッドの戻り値はvoidにする（更新系のメソッドは状態を変更することが目的で、値を返すべきではないため）</li> <li>参照系のメソッドは副作用を持たないようにし、引数のDTOを受け取ってDTOを返す形にする（副作用があると予測しづらくなり、バグの原因になるため）</li> <li>ドメインロジック系のメソッドは純粋関数として実装し、DTOの変換に特化させる（DB操作や外部サービス連携は行わない）</li> </ul> <h3 id="例外処理">例外処理</h3> <ul> <li>例外を投げる箇所はサービス層に集約する</li> <li>API/Controllerの例外ハンドリングはHandler.phpで行う</li> <li>Commandの例外ハンドリングはプレゼンテーション層内で行う</li> </ul> <h3 id="バリデーション">バリデーション</h3> <ul> <li>プレゼンテーション層ではプリミティブ型のデータ形式のバリデーションを行う</li> <li>サービス層では仕様のバリデーションを行い、不正な場合は例外を投げる</li> </ul> <h3 id="インジェクション">インジェクション</h3> <ul> <li>プレゼンテーション層（Command / Controller）では以下のルールでユースケースを受け取る <ul> <li>1Command/Controller1アクションならメソッドインジェクションでユースケースを受け取る</li> <li>1Command/Controller複数アクションならコンストラクタインジェクションでユースケースを受け取る</li> </ul> </li> <li>ユースケース層ではコンストラクタインジェクションでサービスを受け取る :::</li> </ul> <h2 id="頭が整理されると手が止まらなくなる">頭が整理されると、手が止まらなくなる</h2> <p>思想を整理し、ルールを定義し、ドキュメントに記載することで予想外のメリットがありました。<strong>リファクタリングの作業効率が格段に上がったのです。</strong></p>https://example.org/posts/20260418-01/Sat, 18 Apr 2026 09:00:00 +0900https://example.org/posts/20260418-01/<p>通勤中だったり始業時間までの時間にはてブ見ながら情報収集するのがルーティンなんですが、休日とかはもっと情報収集したいなーと思ってたんです。 スタバとかでMacで見てたらなんかかっこいいかもだし</p> <h2 id="作りたかったもの">作りたかったもの</h2> <p>平日は６時に起きて7:30には会社にいるか、エニタイムにいるか、コメダ珈琲で小倉トースト食べてるかなので、毎朝６時に自動実行されているといいなと思いました。 20以上のテックブログやニュースサイトから記事を収集して、Claude api　でジャンル分析してGithub Issueとして登録するシステムです。 収集するテックブログは<a href="https://qiita.com/tomox1001/items/384e27b6259efdb6064e">永久保存版！エンジニア向け情報収集サイトをまとめてみた【定期更新】</a>とAIKIDOのセキュリティブログとかそんなんです。</p> <h2 id="機能">機能</h2> <ul> <li>毎朝06:00に自動実行(Github Actions)</li> <li>テックブログ・ニュースサイトから記事を収集</li> <li>ジャンルごとにGithub Issueを自動作成</li> <li>前日取得記事との差分チェック</li> </ul> <h2 id="ディレクトリ構成">ディレクトリ構成</h2> <pre tabindex="0"><code> news-digest/ ├── .github/ │ └── workflows/ │ └── news_digest.yml # GitHub Actions設定 ├── scripts/ │ ├── main.py # メイン処理 │ ├── fetch_news.py # スクレイピング │ ├── summarize.py # Claude API要約・分類 │ ├── create_issues.py # GitHub Issue作成 │ └── utils.py # キャッシュ管理 ├── cache/ │ ├── .gitkeep │ └── articles_cache.json # 前日比較用（自動生成） ├── .gitignore ├── requirements.txt └── README.md </code></pre><h2 id="システムアーキテクチャ">システムアーキテクチャ</h2> <pre tabindex="0"><code> ┌─────────────────────────────────────┐ │ GitHub Actions (JST 06:00) │ └──────────────┬──────────────────────┘ │ ▼ ┌─────────────────────────────────────┐ │ 1. fetch_news.py │ │ - 各サイトをスクレイピング │ │ - BeautifulSoup4で記事抽出 │ └──────────────┬──────────────────────┘ │ ▼ ┌─────────────────────────────────────┐ │ 2. utils.py │ │ - キャッシュと差分チェック │ │ - 新規記事のみ抽出 │ └──────────────┬──────────────────────┘ │ ▼ ┌─────────────────────────────────────┐ │ 3. summarize.py │ │ - Claude API (Haiku)で要約 │ │ - ジャンル自動分類 │ └──────────────┬──────────────────────┘ │ ▼ ┌─────────────────────────────────────┐ │ 4. create_issues.py │ │ - GitHub REST API │ │ - ジャンルごとにIssue作成 │ └──────────────┬──────────────────────┘ │ ▼ ┌─────────────────────────────────────┐ │ 5. キャッシュ更新 &amp; Git Commit │ └─────────────────────────────────────┘ </code></pre><h2 id="実行後のissue">実行後のIssue</h2> <p><img alt="image.png" loading="lazy" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1162351/56f2a6ec-4b33-4687-9b5e-98f16011d467.png"></p>https://example.org/posts/hugo-basics/Fri, 10 Apr 2026 09:00:00 +0900https://example.org/posts/hugo-basics/<p>Hugoを使ったブログ構築の基本的な流れ。</p>https://example.org/posts/docker-tips/Sun, 05 Apr 2026 09:00:00 +0900https://example.org/posts/docker-tips/<p>Dockerを使った開発環境構築のtips集。</p>https://example.org/posts/css-animation/Sat, 28 Mar 2026 09:00:00 +0900https://example.org/posts/css-animation/<p>CSSだけで作れる洗練されたアニメーションの作り方。</p>https://example.org/posts/js-tips/Fri, 20 Mar 2026 09:00:00 +0900https://example.org/posts/js-tips/<p>ES2024以降のモダンなJavaScript記法まとめ。</p>https://example.org/about/Mon, 01 Jan 0001 00:00:00 +0000https://example.org/about/