サイオステクノロジー(Tech.Lab)のブログ - TECH PLAY

TECH PLAY

サイオステクノロジー(Tech.Lab)

サイオステクノロジー(Tech.Lab) の技術ブログ

全739件

挨拶 ども!7月は 技術ブログ×生成AIというニッチなジャンルでブログを執筆 していた龍ちゃんです。Claude Maxプランで本当はコード生成をゴリゴリやらせるべきだけど、7月は登壇資料作成もあったのでブログ×生成AIテーマの執筆が多めでブログが出ちゃいましたね。8月はコード生成のほうもちょこちょこ出す予定です。おかげで投稿開始から3年で200本に届きそうです。 皆さんは技術ブログを書く時、いきなり本文から書き始めていませんか?私も以前はそうだったのですが、書いているうちに「あれ、これも書いたほうがいいかな?」「この構成で大丈夫かな?」と迷いが生じて、気がつくと手が止まってしまうことが多々ありました。 そこで今回は、技術ブログ執筆を効率化する「アウトライン作成術」について詳しく見ていきます。実際に私が検証してきた2つのアプローチ「対話型」と「抽出型」を比較しながら、どちらがあなたに合うかを一緒に考えていきましょう! なぜアウトラインが技術ブログ執筆の要なのか まず、そもそもなぜアウトラインを作るといいのでしょうか? 私の経験上、一番大きなメリットは 執筆時に迷うことが少なくなる 点です。文章を書くのと技術検証するのは、それぞれ使う脳の機能が違うんですよね。執筆中に「これも検証したほうがいいかな?」と考え始めると、思考のスイッチングコストが発生して効率が落ちてしまいます。 さらに、アウトラインを事前に作っておくことで以下のような構造の検証もできます: ブログ全体の構成がおかしくないか 長すぎるから分割したほうがいいか 読者にとって情報に過不足がないか SEO観点からブログが長すぎないか 実際、私もアウトラインの段階で「これは長いので内容を削りたいが、SEO的に残すべき内容や分割すべき内容はないか」をClaudeに相談し、必要に応じてシリーズ化することもあります。こうすることで執筆時間だけに注力でき、非常に効率的なんです。 2つのアプローチ:あなたはどっちタイプ? アウトラインを生成する方法として、私が実践しているのは主に2つのアプローチです。 対話型アプローチ:計画重視で体系的に 適用場面: 構想段階・計画重視 向いている人: 論理的思考タイプ これは書く内容があまり決まっていない状態や検証前の段階で有効な方法です。「こんな感じのブログを書きたい」「こういうことを検証しようと思っている」ということをClaudeに伝えて、一緒にアウトラインを作っていきます。 この方法のいいところは、 対話しながら自分の考えを整理できる 点ですね。ブログ制作の初期段階、特に検証前であれば、構想の整理ができるというメリットがあります。 プロンプトサンプル: 技術記事のテーマ:React Hooks入門 想定読者:React初心者(JavaScript基礎は理解済み) 記事の目的:useStateとuseEffectを実際に使えるようになってもらう 読者が理解しやすい論理的な流れで大項目を5個程度生成してください。 各項目では何を説明すべきかも含めて提案してください。 龍ちゃん ※実際のプロンプトはもっとざっくりとした投げかけから始まることが多いです。詳細なやり取りは こちら で確認できます。 抽出型アプローチ:実体験ベースで独自性重視 適用場面: 検証済み内容のブログ化・直感重視 向いている人: アイデア発散タイプ もう一つの方法は、まずざっと書いてしまって、そこからアウトラインを抽出する方法です。これは既に検証した内容をブログにアウトプットするのに適しています。 「こういうことを検証しました」「こんなことをやったんですが、ブログにするならどう構成すればいいですか?」といった感じで、ざっと書いた内容をそのまま入力として与え、そこからアウトラインを抽出してもらいます。 この方法のメリットは、検証内容を全部書いた状態からアウトラインを生成するので、 自分の意図した内容と書きたいことが直接検証結果に基づいている 点です。 プロンプトサンプル: 以下の自由執筆からアウトラインを抽出してください: [検証内容や体験談をそのまま入力] 1. 主要ポイントの抽出 2. 論理的な順序での並び替え 3. 技術ブログ用の見出し構成案 4. 各章の想定文字数 読者が理解しやすい構成になるよう調整もお願いします。 龍ちゃん ※実際のプロンプトはもっと雑な感じです。詳細なやり取りは こちら で確認できます。 最近は音声でブログを書く方法も試しています。音声入力は考えていることを直接文章に反映できるので、おすすめの方法としては、まずざっと話してしまって、検証内容や書こうと思った理由など脳内の情報を全部一旦文章化し、そこからアウトラインを抽出してもらいます。 話した内容には不要な情報や体験談が含まれて冗長になることもありますが、アウトラインでそれらを取捨選択できます。また、「このエピソードは入れたい」といった判断もできるので、話すのが得意な方にとっては、ざっと話した内容からアウトラインを作ってもらう方法が効果的だと思います。 実践例で見る2つの手法の違い 実際に同じテーマで両方の手法を試してみたので、その違いを比較してみましょう。 対話型で作成したアウトライン例 テーマ: Claude×技術ブログ構成編 ## 導入:なぜアウトライン設計が技術ブログの成否を分けるのか - 技術記事でよくある3つの失敗パターン - アウトライン設計で解決できること - 本記事で学べる2つのアプローチ ## 2つのアウトライン生成手法 ### 【手法1】対話型アプローチ - 特徴:Claudeと段階的に構造を組み立て - 向いている人:計画重視、論理的思考タイプ ### 【手法2】執筆先行アプローチ - 特徴:先に自由執筆→後からアウトライン抽出 - 向いている人:直感重視、アイデア発散タイプ ## 読者レベル別の調整ポイント ### 初心者向けの場合 - 前提知識の明示:何を知っていることを前提にするか - 用語解説の配置:どのタイミングで説明するか ### それ以外(中級者以上)の場合 - 前提知識は省略:基本的な説明は最小限に - 応用例・実践例重視:より実務的な内容を 特徴: 体系的で教育的、読者視点重視、チェック機能付き 抽出型で作成したアウトライン例 元素材: 音声入力による自由執筆(今回提供いただいた内容ベース) ## はじめに - 技術ブログ執筆でアウトライン作成が重要な理由 - 執筆時の迷いを削減し、構造検証を可能にするメリット - 2つのアプローチの概要紹介 ## アウトライン作成の2つのアプローチ ### 対話型アプローチ - 適用場面:構想段階・計画重視 - 向いている人:論理的思考タイプ - 手順:Claudeと段階的に構造を組み立て ### 抽出型アプローチ - 適用場面:検証済み内容のブログ化・直感重視 - 向いている人:アイデア発散タイプ - 手順:自由執筆 → アウトライン抽出 → 再構成 ## 実践例による2つの手法の比較 - 対話型で作成したアウトライン例 - 抽出型で作成したアウトライン例 - 2つの手法の違い(比較表付き) ## アウトライン活用のコツ - 手法の使い分け指針 - 品質向上のチェックポイント 特徴: 実体験ベース、具体的で実践的、独自性が高い どちらを選ぶべき?手法の比較 項目 対話型 抽出型 構造 体系的・教育的 実践的・比較重視 向いている人 計画重視・初心者 効率重視・経験者 作成時間 計画長・執筆短 計画短・修正長 文字数目安 3000-4000字 2500-3000字 独自性 汎用性高い 体験談豊富 実際のプロジェクトでどちらを選ぶべきか、迷うところですよね。私の経験では以下のような使い分けをしています: 対話型を選ぶべき場面: 新しい分野について書く時 体系的な解説記事を作りたい時 初心者向けの記事を作る時 抽出型を選ぶべき場面: 実験結果をまとめたい時 体験談を中心とした記事を作る時 音声入力を活用したい時 より効率的なワークフローへの発展 さらに、アウトラインを作ることで、追加で必要な検証内容が見えてきたり、不足部分を早期に発見できたりします。また、今後どういったことを検証すべきかという判断もしやすくなるのも大きなメリットです。 現在私が検証的に取り組んでいるのは、文体抽出も組み合わせた方法です。自分の文体を模倣してもらい、それとアウトライン生成方法を組み合わせています。つまり、話した内容からアウトラインを作り、そのアウトラインと話した内容と文体統一を掛け合わせて、ブログのラフ版を書いてもらうのです。 今後はNotion上で音声入力をして、MCPを使ってClaudeに問い合わせるという方法も考えています。Notionだけで執筆し、その後の修正内容をClaudeから呼び出すことで、執筆時間を大幅に短縮できる予定です。 この辺りの詳細な workflow については、「 Notion×MCP×音声認識でブログを3倍速執筆!完全自動化ガイド 」で詳しく解説していますので、ぜひそちらもご覧ください。 まとめ 今回は技術ブログのアウトライン作成について、2つのアプローチを詳しく見てきました。 対話型 :計画重視で体系的なアウトライン作成に向いている 抽出型 :実体験ベースで独自性の高いアウトライン作成に向いている どちらの手法も、最終的には読者視点での精査が必須ですが、自分のタイプと記事の性質に応じた使い分けが重要ということがわかりました。 実際にブログを書く手間や作成時間を大幅に削減でき、より多くのブログを公開したり検証時間を確保したりできるのがアウトライン作成の大きなメリットです。 皆さんも、ぜひ自分に合った手法でアウトライン作成にチャレンジしてみてください!そのほかにもClaude×技術ブログで情報発信をしています、お楽しみに。 ご覧いただきありがとうございます! この投稿はお役に立ちましたか? 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude活用アウトライン作成術:対話型vs抽出型の実践比較【2025最新】 first appeared on SIOS Tech. Lab .
はじめに Git & GitLab入門ブログ Gitマスターへの道の第3回です。前回の Git & GitLab入門ブログ2 Gitマスターへの道「Git操作入門」 では、ローカルPCにGit、VSCodeを導入し、最初のコミットを行うまでの手順を解説しました。 今回は、チーム開発で使うコマンド、コミットを戻す際に使用するコマンドについて紹介します。 チーム開発で行うことがある操作 まずは前回説明したGit操作を踏まえて、実際のチーム開発でよく使うコマンド(操作)について活用例を交えて紹介していきます。 git log Gitリポジトリのコミット履歴を表示するコマンドです。履歴を見るだけでなくオプションによってプロジェクトの過去の分析や問題の原因究明に役立てることができます。 チーム開発での活用例 バグ特定:特定の機能がいつ、誰によって導入されたか、どのコミットが原因でバグが発生したかを追跡 マージコンフリクトの原因究明:複雑なマージの前に履歴を確認することで、コンフリクトの発生源究明に役立つ オプション git log –oneline : 各コミットを1行で簡潔に表示します。 git log –graph –oneline –all : ブランチの分岐・結合をグラフィカルに表示し、全てのブランチの履歴を1行で表示します。 git log -p <ファイル名> : 特定のファイルの変更履歴と差分を表示します。 git log –author=”<著者名>” : 特定の著者が行ったコミットのみを表示します。 git log –grep=”<キーワード>” : コミットメッセージに特定のキーワードを含むコミットを検索します。 以下はGitリポジトリのコミット履歴を表示するgit logの使用例です。 git logの使用例 今回の例ではコミット履歴を新しい順に表示しています。 commit から始まる複数のブロックが、それぞれ過去に行われた変更(コミット)を表しています。mainブランチへのコミット日時やコメント、設定している場合は誰が行ったかなどが表示され、チーム全体での変更履歴の確認が可能です。 git diff gitの差分を表示するためのコマンドです。 インデックスとワークツリーの差分(addしていない手元の変更点)やコミットとワークツリーの差分などを確認することができます。 チーム開発での活用例 コミット前の最終確認:コミットする前に、意図しない変更が含まれていないかを確認します。 コードレビュー:他のメンバーの変更内容をレビューする際に、差分を確認します。 以下の画像はまだステージングされていない、ワーキングツリー(作業ディレクトリ)での変更内容を表示するgit diffコマンドの使用例です。 git diffの使用例   git diff の出力を見ることで、コミットしようとしている変更が、どのファイルに、どの行が、どういった内容で追加・削除されたかを明確に把握することができます。 git tag 特定のコミットにタグをつけたり、タグの確認をするコマンドです。 タグを使用することでコミットを分かりやすく保管することができます。 チーム開発での活用例 重要なポイントの記録: v1.0.0 , v2.1.0 のように、ソフトウェアのリリースバージョンにタグを付け、後からその時点のコードを簡単に参照できるようにします。 リリースバージョンの管理:特定の重要なマイルストーンや、大きな変更があったコミットにタグを付けて、履歴を分かりやすくします。 以下の画像は最新のコミットに対してタグを作成するgit tagの使用例です。 git tagの使用例 最新のコミットへ `v1.0-beta`というタグを作成することで、その後はgit show (タグ名) などのコマンドを使用することでコミット内容を簡単に確認出来るようになります。 .gitignore .gitignore はコマンドではなく、Gitリポジトリに配置されるファイルです。 .gitignoreにファイル名やディレクトリ名を記載することで、Gitの追跡対象からそれらを無視させることができます。ルートだけでなくサブディレクトリにも配置することができ、その場合、そのファイルが置かれたディレクトリとそのサブディレクトリにルールが適用されます。 チーム開発での活用例 リポジトリをきれいに保つ: 不要なファイルやバージョン管理の対象にしたくないファイルやディレクトリがコミットされるのを防ぎ、リポジトリのサイズを小さく保ちます。 バージョン管理の対象にしたくないファイルとはコンパイル時やエディタが自動生成するファイル( dist/ , build/ )やライブラリ依存のファイル(node_modules/)、キャッシュファイル( __pycache__/ , .pytest_cache/ )などがあります。 環境変数、機密情報などGitから除外:公開リポジトリや誤って共有してしまった場合のセキュリティリスクを減らします。 以下画像は.gitignoreファイルの例です .gitignoreの作成例 主にPythonでの開発時の不要ファイルを定義しています。 コミットの戻し方 チーム開発時では意図しない内容をコミットへ含めてしまったり、前の状態へ戻したいなどの状況が発生します。 そのような状況でもgitではコミットをコマンドで取り消すことができます。 状況によりコマンドの使い分けが必要です。 git revert すでにリモートにpushしている場合 git revertを使います。 git revertは間違ったコミットを打ち消す新しいコミットを追加して取り消します。元のコミットは残ったままです。 以下画像はgit revertの使用例です。 コミットハッシュを使用してgit revertを使用する例 ↑コミットをpushしたのちgit revertコマンド実行 git revert実行後の編集画面 ↑git revertコマンド実行後のコミット内容編集画面 編集後再度pushする際の例 ↑git revert後コミットを再度push これによりgit revertを使用して打ち消したいコミットの内容を打ち消す内容のコミットがpushされます。 VScodeから実行する場合以下のようになります git revertをVScodeから実行する例 git reset コミット履歴自体を操作する強力なコマンドです。いくつかオプションがありますが、ここではよく使うものを簡単に紹介します。 git reset –soft [コミットID]: 指定したコミットの状態に戻しますが、ファイルの変更内容はそのまま残し、ステージングされた状態にします。 git reset –mixed [コミットID] (デフォルト): 指定したコミットの状態に戻し、ファイルの変更内容も残しますが、ステージングは解除されます。 git reset –hard [コミットID]: 指定したコミットの状態に戻し、指定したコミットIDの状態にプロジェクト全体を完全に巻き戻します。普段作業しているPC上のプロジェクトフォルダやステージングエリアもすべて破棄します。 この操作は非常に危険で、元に戻すことができないため、使用には細心の注意が必要です。 git resetは履歴そのものを書き換えて取り消しします。git resetでpush後のコミットを操作すると他のチームメンバーにも影響が有るため、非常に危険な操作だと意識しましょう。 以下の画像は 直前のコミットを取り消しつつ、変更内容は残すgit reset –soft HEAD~1の使用例です git reset –soft HEAD~1の使用例 VScodeから実行する場合以下のようなります git resetをVScodeから実行する例 git restore git restore は、コミットされた履歴ではなく、ワークツリー(手元のファイル)やステージングエリア( git add した変更)の変更を元に戻すために使用するコマンドです。 git reset よりも粒度が細かく、安全です。 以下はコマンドでのステージングエリアの変更取り消しの実行例です。 git restoreの使用例 VScodeで実行する場合以下のようになります git restoreをVScodeで実行する例 まとめ 今回はチーム開発で使うコマンド、コミットを戻す際に使用するコマンドを紹介しました。これでGitを使ったチーム開発において、コードの変更管理と履歴の追跡をよりスムーズに行うことが出来るようになります。 次回は、Gitを使った共同開発の基本として、リモートリポジトリの役割やクローン、SSH設定、そして変更を反映する一連の流れを詳しく解説します。 参考文献 https://qiita.com/shibukk/items/8c9362a5bd399b9c56be https://qiita.com/growsic/items/ed67e03fda5ab7ef9d08 https://qiita.com/anqooqie/items/110957797b3d5280c44f https://envader.plus/article/244 https://envader.plus/article/448 ご覧いただきありがとうございます! この投稿はお役に立ちましたか? 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Git & GitLab 入門 (3) ~Git マスターへの道~「Git操作チーム利用コマンドや ロールバック」 first appeared on SIOS Tech. Lab .
はじめに ども!Claude関連のブログを週に5本も投稿してしまって燃え尽きている龍ちゃんです。登壇資料完成までもう少しなので、今週の残りを走り切ろうと思います。 Claude×技術ブログというテーマ でハイペースでブログを執筆しています。 そんな中、今回の登壇資料作成にClaudeが大活躍して、なんと 爆速で登壇資料作成が終わった んです! 衝撃の効率化実績 従来:40時間/本 × 2本 = 80時間 新手法:11時間で2本完成(3時間生成 + 5時間修正 × 2本) 結果:約7倍の効率化を実現 45分の登壇資料を3時間で作る、これって革命的じゃないですか? この記事で得られること ブログ記事を登壇資料に変換する実用的な方法 Claude×Marpによるエンジニア最適化ワークフロー 実際に使えるプロンプト例とコード 現実的な課題と対処法(包み隠さず全部話します!) 実際の成果物 今回作成したコンテンツはすべて、GitHubとGitHub Pagesに公開しています。ぜひ見てみてください。 参考 Claude AI活用技術セミナー – 登壇資料ハブ 参考 GitHub – Ryunosuke-Tanaka-sti/claude_and_blog_seminar GitHub 基本ワークフロー(シンプルな3ステップ) Claude×Marpによる登壇資料作成は、以下の3ステップで完了します。Claude Codeの実行環境を準備することで、Marp形式のMarkdownをスムーズに編集・更新できます。 ステップ1:ブログ記事をClaudeに読み込ませる 最初に、既に執筆済みのブログ記事をClaudeに読み込ませ、ドキュメントとして参照できる状態にします。 一次情報の活用 :すでに執筆済みの内容なので、信頼性が担保されています 複数ブログの参照 :関連する複数のブログを参照させることで、より充実した登壇資料を短時間で作成できます ステップ2:登壇情報を明確化してMarp形式で生成 高品質な登壇資料を作成するためには、 登壇に関する基本情報を整理 することが重要です。 対象者 :どのようなレベル・バックグラウンドの人か 時間 :登壇時間はどれくらいか 目的 :何を伝えたいのか これらの情報とブログの内容を組み合わせて、ClaudeにMarp形式で登壇資料を生成してもらいます。 メリット : MarpはMarkdown形式での記述のため、エンジニアにとって操作しやすく、バージョン管理も容易です。 ステップ3:VSCodeで微調整とプレビュー Claudeが生成した初期草案をベースに、VSCode上でリアルタイムプレビューを確認しながら編集を行います。 主な調整作業 : 内容の追加・修正 :特定の部分を詳しく追記、関連情報の補強 スライド構成の最適化 :情報量の調整、ページ分割の精練 ビジュアル調整 :フォントサイズ、レイアウトの微調整 効率的な作業環境 : VSCodeのMarp拡張機能を使用することで、コード編集とプレゼンテーションのプレビューを同時に行えるため、作業効率が大幅に向上します。 実際の手順(今すぐ試せる具体的方法) 環境準備(5分で完了) # VSCode拡張機能のインストール - Marp for VS Code - Markdown Preview Enhanced(推奨) Claude用プロンプト例(コピペOK) 以下のブログ記事を基に、45分の技術登壇用資料をMarp形式で作成してください。 【対象者】:エンジニア(経験年数3-5年) 【時間】:45分 【目的】:実践的な知識共有 【ブログ記事】: [ここにブログ記事をペースト] or [MCP経由で取得] 【要件】: - スライド数:25-30枚程度 - 実装例やコード例を含める - 質疑応答用のスライドも追加 - Marp形式で出力 Marpの基本設定 --- marp: true theme: default paginate: true header: '登壇タイトル' footer: 'あなたの名前 | 日付' --- 生成から完成までの流れ Claude出力をコピー (約30秒) VSCodeで新規.mdファイル作成 (約1分) プレビュー確認 (Ctrl+K → V) 内容調整 (30分-2時間) エクスポート (約2分) 制約と現実的な対処法 Marpが苦手なこと Claudeと実際に試してみたところ、いくつか苦手な部分がわかりました: 複雑なレイアウト 対処法:シンプルなデザインに徹する 個人的に「デザインよりもコンテンツの方が重要」と考えるようになりました 凝った図表作成 対処法:図にしたい部分はHTMLで出力してもらい、そのHTMLをベースに図表を作成してSVGで埋め込む これは現実的な手法だと思います 情報の詰め込みすぎ 一枚のスライドに収まりきらない情報を書いてしまったり 図で表現すべき内容を文章で表現してしまうことがあります 対処法:何を図にするかという判断には、やはり人間の目が必要 人間による最終調整が必要な部分 現状、Marpで出力した資料をそのまま使えるケースはそれほど多くないと思います。 図 vs 文章の判断 :AIは文章で説明しがち スライド分割 :1枚に情報を詰め込む傾向 フォントサイズ調整 :読みやすさの最終確認 ただし、ブログをもとに生成された文章自体は使えるので、図の配置などに関して人間が確認しながら修正すれば十分実用的です。 PowerPointとの使い分け Marp向き : コンテンツ重視 情報密度高め エンジニア向け技術発表 PowerPoint向き : デザイン重視 営業資料 視覚効果重要な場面 レイアウトにこだわらなければMarpで登壇資料を作るのはすごく効率的です。Marpで資料を作り、それをベースにパワーポイントなどで編集するというのも現実的なアプローチだと個人的に感じています。 実際の成果と品質評価 生成品質 文章品質 : そのまま使用可能レベル 構成力 : 論理的で分かりやすい流れ 技術精度 : ブログベースなので一次情報で正確 デザイン : シンプルだが実用的 時間短縮の内訳 .work-time-comparison-container { font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif; margin: 20px auto; padding: 0; background: #f5f6fa; border-radius: 8px; max-width: 800px; box-sizing: border-box; width: 100%; } .work-time-comparison-container * { box-sizing: border-box; } .work-time-comparison-wrapper { background: white; border-radius: 8px; box-shadow: 0 4px 12px rgba(0,0,0,0.1); overflow: hidden; } .work-time-comparison-header { background: #2f3542; color: white; text-align: center; padding: 20px; } .work-time-comparison-header h1 { margin: 0; font-size: 1.8em; font-weight: 300; } .work-time-comparison-subtitle { margin-top: 8px; font-size: 1em; opacity: 0.9; } .work-time-comparison-content { padding: 20px; } .work-time-comparison-section { display: flex; gap: 20px; margin-bottom: 30px; align-items: flex-start; } .work-time-comparison-before-after { flex: 1; } .work-time-comparison-section-title { font-size: 1.4em; margin-bottom: 20px; text-align: center; padding: 12px; border-radius: 6px; font-weight: bold; } .work-time-comparison-before .work-time-comparison-section-title { background: #ff4757; color: white; } .work-time-comparison-after .work-time-comparison-section-title { background: #3742fa; color: white; } .work-time-comparison-task-item { display: flex; align-items: center; margin-bottom: 15px; padding: 15px; background: #f8f9fa; border-radius: 6px; transition: transform 0.3s ease; position: relative; width: 100%; } .work-time-comparison-task-item:hover { transform: translateY(-2px); box-shadow: 0 5px 15px rgba(0,0,0,0.1); } .work-time-comparison-task-name { flex: 1; font-weight: 600; font-size: 0.95em; color: #2d3748; margin-right: 10px; } .work-time-comparison-task-time { font-weight: bold; font-size: 1.1em; padding: 8px 12px; border-radius: 4px; min-width: 70px; text-align: center; } .work-time-comparison-before .work-time-comparison-task-time { background: #ffcccc; color: #d63031; } .work-time-comparison-after .work-time-comparison-task-time { background: #cce5ff; color: #0984e3; } .work-time-comparison-time-bar { height: 8px; background: #e9ecef; border-radius: 4px; margin: 10px 0; overflow: hidden; } .work-time-comparison-time-fill { height: 100%; transition: width 1s ease; border-radius: 4px; } .work-time-comparison-before .work-time-comparison-time-fill { background: #ff4757; } .work-time-comparison-after .work-time-comparison-time-fill { background: #3742fa; } .work-time-comparison-total-section { background: #5352ed; color: white; padding: 20px; border-radius: 6px; text-align: center; margin-top: 30px; } .work-time-comparison-total-comparison { display: flex; justify-content: space-around; align-items: center; margin-top: 15px; } .work-time-comparison-total-item { text-align: center; } .work-time-comparison-total-number { font-size: 2.2em; font-weight: bold; margin-bottom: 5px; } .work-time-comparison-total-label { font-size: 1em; opacity: 0.9; } .work-time-comparison-arrow { font-size: 2em; opacity: 0.7; animation: work-time-comparison-pulse 2s infinite; } @keyframes work-time-comparison-pulse { 0%, 100% { opacity: 0.7; } 50% { opacity: 1; } } .work-time-comparison-efficiency-badge { position: absolute; top: -8px; right: -8px; background: #2ed573; color: white; padding: 4px 8px; border-radius: 4px; font-size: 0.8em; font-weight: bold; box-shadow: 0 2px 6px rgba(46,213,115,0.3); } .work-time-comparison-savings { background: #ff6348; color: white; padding: 15px; border-radius: 6px; margin-top: 15px; text-align: center; } .work-time-comparison-savings-title { font-size: 1.2em; font-weight: bold; margin-bottom: 8px; } .work-time-comparison-savings-amount { font-size: 2em; font-weight: bold; } @media (max-width: 768px) { .work-time-comparison-container { margin: 5px; padding: 0; max-width: none; width: calc(100vw - 10px); } .work-time-comparison-content { padding: 10px; } .work-time-comparison-section { flex-direction: column; gap: 20px; width: 100%; } .work-time-comparison-before-after { width: 100%; flex: 1; } .work-time-comparison-task-item { display: flex; flex-direction: row; align-items: center; justify-content: space-between; padding: 10px 12px; width: 100%; box-sizing: border-box; } .work-time-comparison-task-name { flex: 1; margin-right: 10px; margin-bottom: 0; font-size: 0.9em; min-width: 0; } .work-time-comparison-task-time { min-width: 50px; font-size: 0.9em; padding: 4px 8px; flex-shrink: 0; } .work-time-comparison-time-bar { display: none; } .work-time-comparison-total-comparison { flex-direction: row; gap: 10px; justify-content: space-evenly; width: 100%; } .work-time-comparison-arrow { font-size: 1.2em; transform: none; } .work-time-comparison-section-title { font-size: 1.1em; padding: 8px; margin-bottom: 15px; width: 100%; box-sizing: border-box; } .work-time-comparison-header { padding: 15px 10px; width: 100%; } .work-time-comparison-header h1 { font-size: 1.3em; } .work-time-comparison-subtitle { font-size: 0.85em; } .work-time-comparison-efficiency-badge { position: absolute; top: -6px; right: -6px; padding: 2px 5px; font-size: 0.7em; } .work-time-comparison-total-number { font-size: 1.6em; } .work-time-comparison-total-label { font-size: 0.9em; } .work-time-comparison-total-section { padding: 15px 10px; width: 100%; box-sizing: border-box; } .work-time-comparison-total-item { flex: 1; text-align: center; } } @media (max-width: 480px) { .work-time-comparison-container { margin: 2px; width: calc(100vw - 4px); } .work-time-comparison-content { padding: 8px; width: 100%; } .work-time-comparison-task-item { padding: 8px 10px; margin-bottom: 10px; width: 100%; } .work-time-comparison-task-name { font-size: 0.85em; flex: 1; min-width: 0; overflow: hidden; text-overflow: ellipsis; white-space: nowrap; } .work-time-comparison-task-time { font-size: 0.85em; padding: 3px 6px; min-width: 45px; flex-shrink: 0; } .work-time-comparison-total-section { padding: 12px 8px; width: 100%; } .work-time-comparison-savings { padding: 10px 8px; width: 100%; box-sizing: border-box; } .work-time-comparison-savings-title { font-size: 1em; } .work-time-comparison-savings-amount { font-size: 1.4em; } .work-time-comparison-header { padding: 12px 8px; width: 100%; } .work-time-comparison-header h1 { font-size: 1.2em; } .work-time-comparison-subtitle { font-size: 0.8em; } .work-time-comparison-section-title { font-size: 1em; padding: 6px; width: 100%; } .work-time-comparison-efficiency-badge { font-size: 0.65em; padding: 1px 4px; } .work-time-comparison-total-number { font-size: 1.4em; } .work-time-comparison-total-label { font-size: 0.8em; } .work-time-comparison-total-item { flex: 1; min-width: 0; } } 作業時間効率化比較 従来の手法 vs Claude + Marp活用 従来の手法 構成検討 8時間 内容執筆 20時間 デザイン調整 10時間 微調整 2時間 Claude + Marp活用 構成検討 (Claude) 5分 96倍効率化 内容執筆 (Claude) 5分 240倍効率化 デザイン調整 (Marp) 1時間 10倍効率化 微調整 (人間) 2-5時間 // WordPress環境でのアニメーション効果 (function() { function initWorkTimeComparisonAnimation() { const timeFills = document.querySelectorAll('.work-time-comparison-time-fill'); timeFills.forEach(fill => { const width = fill.style.width; fill.style.width = '0%'; setTimeout(() => { fill.style.width = width; }, 500); }); } // ページ読み込み完了後またはDOMContentLoaded後に実行 if (document.readyState === 'loading') { document.addEventListener('DOMContentLoaded', initWorkTimeComparisonAnimation); } else { initWorkTimeComparisonAnimation(); } })(); 管理面でのメリット Marpで資料を管理しておくと、通常登壇資料はドライブに保存するだけで参照情報をすべて記録することは少ないものですが、この方法では参照した情報がすべて保存された状態になり、管理の面でも優れています。 また、MarpでVSCodeのデザインファイルを作成できるので、CSSでプロパティを編集して自分の登壇資料のベースデザインを作成できます。CSSを書くのが苦手な人も多いと思いますが、AI入力に適した形式になっていると個人的に感じています。 まとめ この手法が向いている人 既にブログを書いているエンジニア コンテンツ重視の登壇をする人 効率化を重視する人 マークダウンに慣れている人 この手法が向いていない場面 デザイン性を重視する営業資料 複雑な図表が多数必要な資料 ブランディング重視のプレゼン 今日から始められるアクション VSCodeにMarp拡張機能をインストール 過去のブログ記事を1つ選ぶ 上記のプロンプトをClaudeに投入 5分で最初のスライドを生成体験 将来的な展望 これは将来的な展望になりますが、Marpで第一段階の資料を作成し、その構造化情報をもとに別のAIに入力してデザインを整えてもらうという方法も検討しています。 次回予告 具体的な応用例 :技術勉強会での実際の使用例 高度なカスタマイズ :CSSでのデザイン調整 チーム運用 :複数人でのMarp資料管理 皆さんも、ぜひこの方法で登壇資料作成の効率化にチャレンジしてみてください! 補足情報 参考リンク Marp公式サイト VS Code Marp拡張機能 動作環境 VSCode(最新版推奨) Node.js(Marp CLI使用時のみ) Claude Code ご覧いただきありがとうございます! この投稿はお役に立ちましたか? 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【ブログ→登壇資料】Claude×Marpで80時間を11時間に短縮した方法 first appeared on SIOS Tech. Lab .
はじめに データベースとWebアプリケーションの連携について学ぶため、PostgreSQLとNode.js、Expressを使って従業員管理システムのREST APIを構築してみました。本記事では、環境構築から実際のAPI作成まで、初心者の視点で学んだことをまとめます。 今回作成したもの PostgreSQL 17 を使ったデータベース Node.js + Express によるREST APIサーバー Sequelize を使ったORM実装 CRUD操作 (Create, Read, Update, Delete) の完全実装 環境構築 PostgreSQLのインストール Windows環境では、wingetを使って簡単にインストールできました winget install PostgreSQL.PostgreSQL.17 winget install PostgreSQL.pgAdmin ポイント: PostgreSQLはWindowsサービスとして自動起動 pgAdminでGUI管理が可能 初期設定でパスワードの設定が必要 Node.js環境の準備 プロジェクトの依存関係: { "name": "intro-sq", "dependencies": { "express": "^4.18.2", "pg": "^8.16.3", "sequelize": "^6.37.7" } } 学んだこと: npmパッケージ名は小文字とハイフンのみ使用可能 introSQ → intro-sq への変更が必要だった データベース設計 employeeテーブル CREATE TABLE employee ( id SERIAL PRIMARY KEY, name TEXT NOT NULL UNIQUE, tel TEXT ); 特徴: id :自動採番の主キー name :一意制約付きの必須項目 tel :NULL許可の電話番号 アプリケーション構成 ディレクトリ構造 introSQ/ ├── app.js # メインアプリケーション ├── routes/ │ └── index.js # APIルーティング ├── app/ │ ├── db/ │ │ ├── db-config.js # DB接続設定 │ │ └── db-client.js # CRUD操作 │ └── model/ │ └── employee.js # Sequelizeモデル └── package.json API エンドポイント Method URL 機能 GET /employee/find 全従業員取得 POST /employee/register 新規登録 PUT /employee/update 情報更新 DELETE /employee/remove 削除 実装のポイント 1. Express アプリケーションの基本構造 var express = require('express'); var app = express(); // JSONパーサーミドルウェア app.use(express.json()); app.use(express.urlencoded({ extended: false })); // ルーティング設定 app.use('/', indexRouter); // サーバー起動 app.listen(3000, function() { console.log('Server is running on port 3000'); }); 2. Sequelizeモデル定義 const employee = dbConfig.define('employee', { id: { type: Sequelize.INTEGER, primaryKey: true, autoIncrement: true }, name: { type: Sequelize.STRING }, tel: { type: Sequelize.STRING } }, { timestamps: false, freezeTableName: true }); 3. REST APIの実装 // GET - データ取得 router.get('/employee/find', function(req, res, next) { const query = req.query; dbClient.find(query, function(result) { res.json(result); }); }); // POST - データ登録 router.post('/employee/register', function(req, res, next) { const addData = req.body; dbClient.register(addData, function(result) { res.json(result); }); }); フレームワーク vs ライブラリの理解 フレームワークとライブラリの違いについては、理解があやふやな部分がありましたが、開発を通して両者の違いを理解することができました。 また、ランタイム環境についても理解を深めることができたので、3者の違いをまとめておきます。 フレームワーク Express : アプリケーションの構造を提供 フレームワークが主導権を握る 決められたルールに従ってコードを配置 ライブラリ Sequelize : 特定機能を提供 開発者が必要時に呼び出す 使用方法の自由度が高い ランタイム環境 Node.js : JavaScript実行環境 ブラウザ外でのJavaScript実行を可能に 学習成果 技術的な理解 PostgreSQL : オープンソースのリレーショナルデータベース管理システム Node.js : JavaScriptでサーバーを構築するための実行環境 Express : Node.jsのための軽量なWebアプリケーションフレームワーク Sequelize : Node.js用のORM(DBを簡単に操作するためのライブラリ) 開発スキル 環境構築 : wingetを活用したツール導入 設定管理 : 認証設定とセキュリティ API設計 : RESTful な設計原則 テスト : Postmanによる動作確認 まとめ 今回の学習を通して、モダンなWeb アプリケーション開発の基礎を体験できました。 上述した技術の組み合わせにより、効率的で保守性の高いアプリケーション開発が可能であることを実感しました。 参考リンク PostgreSQL公式ドキュメント Express.js公式サイト Sequelize公式ドキュメント Node.js公式サイト この記事が、同じように学習を始める方の参考になれば幸いです。 ご覧いただきありがとうございます! この投稿はお役に立ちましたか? 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【初心者向け】PostgreSQL & Node.js をまとめてキャッチアップ first appeared on SIOS Tech. Lab .
はじめに ども!今週は大量のブログを執筆しており、このペースだと執筆開始から3年で200本達成ができそうな龍ちゃんです。いや~大量のブログを書きましたね。そんなブログ執筆をさらに早くするためのお話です。 長時間のタイピングで肩が凝る、キーボードから離れた場所では作業できない、文章を書くのに時間がかかりすぎて図作成やサムネイル制作に時間を割けない…そんな課題を抱えている方も多いのではないでしょうか。 今回は、そんな悩みを一気に解決する新しいブログ執筆法をご紹介します。使用するツールは Notion 、 MCP(Model Context Protocol) 、そして Claude の組み合わせです。この方法を使えば、従来のタイピング中心の執筆から脱却し、音声認識を活用した効率的なワークフローを構築できます。 私自身、この方法を導入してから執筆効率が約3倍向上し、しかも疲労感は大幅に軽減されました。特に技術ブログのような専門的な内容でも、人間らしい「生の声」を保ちながら高品質なコンテンツを短時間で制作できるようになったんです。 それでは、具体的なワークフローを詳しく見ていきましょう。 前提環境の構築 まず最初に、この方法を実践するための環境構築について触れておきます。今回のワークフローを実現するためには、 Notion 、 Notion MCP(Model Context Protocol) 、そして Claude Desktop を連携させた環境が必要です。 具体的には以下の構成になります: Notion : ブログの下書きとアウトライン管理 Notion MCP : NotionとClaude間のデータ連携 Claude Desktop : 最終的な文章修正と品質向上 MCPを導入することで、Notionのページやデータベースに直接Claude Desktopからアクセスできるようになり、従来のコピー&ペースト作業が不要になります。この環境構築により、音声入力から最終仕上げまでの一連の流れが非常にスムーズになるんです。 Notion MCPとClaude Desktopの接続方法に関しては、「 Claude×Notion MCP実装術|コネクタ版とIntegration版の選び方解説 」で解説しています。 環境構築の詳細については別の記事で解説予定ですが、一度セットアップしてしまえば劇的に作業効率が向上しますので、ぜひ挑戦してみてください。 4段階のワークフロー 第一段階:アウトライン作成 まず最初に行うのは、Claudeとの会話を通じたアウトライン作成です。これは従来の執筆方法でも重要な工程でしたが、音声入力を前提とするとより一層重要になってきます。 Claudeには「こんなトピックでブログを書きたい」「この技術について解説したい」といった大まかな方向性を伝え、詳細なアウトラインを一緒に作り上げていきます。この段階では、章立てだけでなく、各章で話したい内容を箇条書きレベルまで具体化します。 例えば、今回の記事でも最初に「音声認識を活用したブログ執筆法」というテーマから始まり、「4段階のワークフロー」「メリット」「実践的なコツ」といった大枠を決めた後、それぞれの章で何を話すかを詳細に決めていきました。 従来の方法では「なんとなく」で始めることもありましたが、音声入力では話す内容が事前に整理されていないと、「えーと」「あー」が多くなってしまい、後の修正工程が大変になってしまうんですね。 第二段階:音声入力による執筆 アウトラインが完成したら、いよいよ音声認識での執筆に入ります。ここが今回の方法の最大のポイントです。 作成したアウトラインに沿って、頭の中にある情報をそのままダイレクトに話していきます。この時のコツは、 完璧を求めないこと です。「えーと」「あー」といった思考整理のための言葉も気にせずそのまま話します。言い間違いがあってもそのまま言い直せばOKです。 私の場合、技術的な検証結果や実装時に苦労したポイントなど、リアルタイムで体験したことをそのまま話すようにしています。例えば「この設定でハマったんですよね」「最初はこう思ったんですけど、実際やってみると違って」といった、人間ならではの試行錯誤のプロセスも含めて話します。 音声認識の精度は現在かなり向上しているので、普通に話していれば大体は適切に変換してくれます。私はiPhoneの音声認識を主に使用していますが、Notionアプリでも直接音声入力ができるので非常に便利です。 Before(従来の方法) : キーボードに向かう → 文章を考える → タイピング → 疲れる → 休憩 → また考える… After(音声入力) : アウトライン確認 → 話し始める → 思考がそのまま文字になる → 疲労感なし → 継続して話せる この変化は本当に劇的でした。特に長時間の執筆でも集中力が続きやすくなったのは大きなメリットです。 第三段階:Notion AIでの一次修正 音声入力が完了したら、次はNotion AIを使った一次修正です。ここでの主な目的は、思考の滞留時間に出てくる「えーと」「あー」といった言葉の削除と、基本的な文章の改善です。 Notion AIは非常に優秀で、文脈を理解した上で自然な文章に修正してくれます。音声認識特有の問題として、句読点が適切に入らないことがありますが、Notion AIがかなりの精度で補完してくれるんです。 修正時の具体的な指示例: 「音声入力による不自然な表現を修正して」 「『えーと』『あー』などの間投詞を削除して」 「文章の流れを自然にして」 ただし、この段階では 完璧を求めません 。あくまで一次修正として、明らかに不自然な部分だけを直す程度に留めています。内容の大幅な変更や追加は次の段階で行います。 第四段階:Claudeでの最終修正 最後の仕上げは、MCPを介してNotionからコンテンツを取得し、Claudeで最終的な修正を行います。この段階が、今回のワークフローの真骨頂と言えるでしょう。 ClaudeにはSIOSテックブログの文体やトーンを学習させているので、一次修正された音声入力の内容を、ブログに適した文章に変換してくれます。具体的には: 技術的な正確性の確認 読者にとってわかりやすい表現への変更 情報の整理と補完 ブログ特有の親しみやすい文体への調整 MCPの導入により、NotionとClaudeの連携が非常にスムーズになりました。従来はコピー&ペーストで内容を移す必要がありましたが、今では直接Notionの内容を参照できるため、作業効率が格段に向上しています。 最終チェックポイントとしては: 技術用語の正確性 読者の技術レベルに応じた説明の詳細度 文章の論理的な流れ SIOSテックブログらしい親しみやすさの維持 具体的な方法に関しては、「 Claude技術ブログ品質向上の試行錯誤|3段階チェックで安定【プロンプト実践】 」でまとめています。 この方法のメリット 効率性の向上 まず何といっても、 執筆速度の劇的な向上 が最大のメリットです。私の場合、タイピング速度と比較すると音声入力は約3倍の効率を実現できています。 具体的な時間比較を見てみましょう: 従来の方法(5000文字のブログ) : アウトライン作成:30分 執筆(タイピング):3時間 見直し・修正:1時間 合計:4時間30分 音声認識活用法(同じ5000文字) : アウトライン作成:45分(より詳細に) 音声入力:1時間 Notion AI修正:15分 Claude最終修正:30分 合計:2時間30分 つまり、 約45%の時間短縮 を実現できているんです。しかも、タイピングによる疲労がないため、長時間の継続性も格段に向上しました。 環境の柔軟性 この方法のもう一つの大きなメリットは、 場所を選ばないこと です。キーボードが使える環境でなくても、スマートフォンがあればブログを書けるようになりました。 実際の活用例: 電車での移動中にアウトライン確認→音声入力 カフェでリラックスしながら修正 散歩中にふと思いついたアイデアをその場で録音 外出先での空き時間を有効活用 特にiPhoneの音声認識機能は本当に優秀で、多少の雑音があっても正確に認識してくれます。従来は「パソコンの前に座って集中して」という制約がありましたが、今では思考がまとまったタイミングでいつでもどこでも執筆できるようになりました。 品質向上への時間配分 文字起こし時間が削減されることで、 ブログの品質向上により多くの時間を割けるようになりました 。これは予想以上に大きな変化でした。 時間配分の変化: 従来の配分 : 文章執筆:70% 図作成:20% サムネイル制作:10% 現在の配分 : 音声入力+修正:40% 図作成:35% サムネイル制作:15% 追加調査・検証:10% 結果として、より視覚的でわかりやすいブログを制作できるようになり、社内からの反応も良くなっています(書きすぎちゃって見るのが重いって苦情が来ましたけど…w)。図を作りながら話し続けるというマルチタスクも可能になったため、理想的には同時並行での作業も実現できそうです。 人間らしいコンテンツの維持 AIに一から生成してもらうのではなく、人間の話した内容を基盤とすることで、 生の情報発信 を維持できているのも重要なポイントです。 技術ブログにおいて、人間の葛藤や苦労、試行錯誤のプロセスは非常に価値があります。AIは「詰まる」ことがなく、間違っていても「動きます」と言ってきたりしますが、実際のエンジニアは様々な課題に直面しながら解決策を見つけていくものです。 音声入力により、そうした「生の声」を自然にコンテンツに反映できるようになりました。「ここで実際にハマったんですよね」「最初はうまくいかなくて」といった、リアルな体験談が自然に含まれるため、読者にとってより価値のあるコンテンツになっているはずです。きっと… 実践上の変化と工夫 アウトライン作成の重要性 音声入力を導入してから、 アウトライン作成により丁寧に取り組むようになりました 。これは話す内容を事前に整理しておいた方が圧倒的に話しやすいからです。 具体的な変化: 章立てだけでなく、各章の要点まで箇条書きで整理 話したい順序を明確に決定 技術用語や固有名詞を事前にリストアップ 想定される読者の疑問点も事前に洗い出し 例えば今回の記事では: ## 第二段階:音声入力による執筆 - アウトラインに沿って話す - 完璧を求めない - 「えーと」「あー」も気にしない - 実体験を交える - Before/After例を示す このレベルまで決めておくと、頭の中での思考スピードも向上し、話している最中に「これも追加しよう」という気づきも生まれやすくなります。 AIの活用方針 重要なのは、 AIに一から生成してもらうのではなく、人間の話した内容を補正してもらう という使い方です。これにより、以下の効果を得られています: 情報源は自分の頭から出たものなので信頼性が高い 人間ならではの体験談や失敗談が含まれる 技術的な詰まりポイントや試行錯誤が自然に表現される AIでは表現できない「葛藤」が記事に含まれる AIと人間の役割分担を明確にすることで、効率性と人間らしさの両方を実現できているのが、この方法の大きな特徴だと思います。 音声入力のコツと注意点 精度向上のポイント 音声認識の精度を上げるためのコツをいくつかご紹介します。まず何といっても 滑舌 が重要です。現在の音声認識技術はかなり向上していますが、やはり明瞭な発音の方が精度が高くなります。 実践的なコツ: 言い間違いは音声認識を止めずにそのまま言い直す 一文が長くなりすぎないよう適度に区切る 専門用語はゆっくりめに発音する 環境音が多い場所では少し大きめの声で話す おすすめの音声認識アプリとしては、iPhoneの標準機能が最も優秀だと感じています。Notionアプリでも直接音声入力ができますし、GoogleドキュメントやMicrosoft Wordでも音声入力機能が充実しています。 修正が必要な要素 音声認識で特に注意が必要なのは、 技術用語や固有名詞の認識精度 です。ここは現在でも課題が残っている部分ですね。 よくある誤変換パターン: 「Claude」→ 「黒田」「クラウド」 「GitHub」→ 「ギットハブ」「Git Hub」 「API」→ 「エーピーアイ」「a P I」 「AWS」→ 「あws」「アマゾン」 製品名などは特に変換ミスが起きやすく、文脈から見て明らかにおかしな変換になることがあります。例えば技術ブログで急に「黒田さん」が登場したら、それはおそらく「Claude」の誤変換だと推測できますよね。 こうした部分は 後から手動で修正する ことを前提として、音声入力時はあまり気にせずに話し続けることが効率的です。 AIへの事前情報提供 ClaudeやNotion AIに修正を依頼する際は、 適切な固有名詞を事前に提供する と、かなり優秀に補正してくれるようになります。 例えば: 以下の音声入力文章を修正してください。 技術用語は正確に表記してください。 使用している技術はClaude・GitHub・Notionなどです。 このように事前情報を提供することで、AIの文脈理解が向上し、より自然で正確な修正結果を得られるようになります。 まとめ 今回は、音声認識を活用したブログ執筆法について詳しくご紹介しました。Notion、MCP、Claudeを組み合わせた4段階のワークフローにより、従来のタイピング中心の執筆から大幅な効率向上を実現できています。 重要なポイントをまとめると: 音声入力により執筆効率が約3倍向上 場所を選ばない柔軟な執筆環境を実現 品質向上により多くの時間を配分可能 人間らしい「生の声」を維持したコンテンツ制作 特に技術ブログにおいては、エンジニアの実体験や試行錯誤のプロセスが読者にとって非常に価値があります。AIだけでは表現できない「人間の葛藤」を自然に含めながら、効率的にコンテンツを制作できるこの方法は、多くの技術ブロガーにとって有効だと思います。 現在はこのワークフローをさらに発展させ、 タイトル作成やメタディスクリプション生成 なども含めた包括的なブログ制作システムを構築しています。そちらについても、また別のブログで詳しく紹介しますね。 皆さんも、ぜひ音声認識を活用したブログ執筆にチャレンジしてみてください!最初は慣れないかもしれませんが、一度コツを掴めば手放せなくなるはずです。何か質問があれば、コメントでお気軽にお声がけくださいね。 ご覧いただきありがとうございます! この投稿はお役に立ちましたか? 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Notion×MCP×音声認識でブログを3倍速執筆!技術者向け効率化ワークフロー解説 first appeared on SIOS Tech. Lab .
  こんにちは、サイオステクノロジーの佐藤 陽です。 本日は、最近話題が尽きることのない「AIエージェント」についてご紹介したいと思います! とは言いつつ、最新のトピックに関する内容ではなく そもそも「AIエージェント」とは何か?といった、根本に立ち返った内容となっています。 RAGは分かった!次はAIエージェントだ! AIエージェントって最近よく聞くけどよく分かんない AIエージェントについてざっくり知りたい といった方は是非、最後までご覧ください! はじめに 本記事は、 こちら の記事を非常に参考にしており、元記事に対して、 理解を容易にするための追記 自分なりの解釈の加筆 をおこなったものです。 そのため、元記事と内容が重複していかと思いますがこの点、了承いただければと思います。 そして本記事を読んで興味を持った方がいたら、是非元の記事も読んでいただければと思います。 ちなみに元記事は、オライリーの AI Engineering という書籍の筆者が、書籍の内容を一部抜粋したものということです。 まだ日本語版が発売していないようなので、今後の発売に期待です。 AIエージェントとは AIエージェントの定義については様々な場面で、様々な定義がされております。 これはまだまだAIエージェントが新興分野であることが要因です。 今回ご紹介する内容についても、あくまで複数ある定義のうちの1つであることを踏まえて読んでいただければと思います。 それではAIエージェントの定義について考えていきます。 まずはAIエージェントを 「AI」 と 「エージェント」 の要素に分解し、それぞれを定義を見ていきたいと思います。 AIとは まずは「AI」とは何かについてですが、NTTデータさんの ページ に以下のように定義されていました。 いま最も注目されているテクノロジーの1つに人工知能(AI:Artificial Intelligence)があります。AIは、一般的には「人が実現するさまざまな知覚や知性を人工的に再現するもの」という意味合いで理解されています。 しかし実際には、AIに対して一意に決まった定義がなされているわけではありません。コンピューター・サイエンスや認知科学、医学、心理学、さらには哲学にいたるまで、今もさまざまな立場で論じられ続けている領域です。 これは最近の様々なAIサービスの登場により、実感できている部分かと思います。 例えば、ChatGPTは人間のように考え質問に対して答えることができます。 他にも人間のように絵を描いたり、作曲するサービスなど、知覚や知性を再現するサービスが多く存在しています。 エージェントとは 次に、「エージェント」についてです。 エージェントとは、 環境 を認識し、その環境に応じて 行動 できるもののことです。 『Artificial Intelligence: A Modern Approach』 (1995) では、エージェントを、センサーを通じて環境を認識し、アクチュエータを通じてその環境に応じて行動できるものとして定義しています。 これにより、エージェントは「環境」と「実行出来るアクションのセット」によって構成されることが分かります。 環境 ではまず環境とは何を示すのでしょうか? これは、ユースケースによって異なります。 例えば、自動運転を行うエージェントであれば「道路状況」が環境となります。 一方で、株の売買を行うエージェントであれば「社会情勢」や「株価指数」などが環境となります。 アクションセット 次にアクションとは何を示すのでしょうか? こちらも環境と同様、ユースケースによって異なります。 自動運転エージェントであれば、車の操作、例えば「アクセルを踏む」や「ハンドルをきる」といった操作がアクションに該当します。 一方で、株の売買を行うエージェントであれば、「社会情勢を調査する」、「株を売る」といった内容がアクションに該当します。 AIエージェントにおけるAIの役割 ここまででAIエージェントとは何かについて、なんとなく分かっていただけたのではないかと思います。 ではAIエージェントを実現するにあたって、AIはどういった役割をしているのでしょうか。 そもそもAIエージェントの目的は、 ユーザーから与えられたタスクを実行し、完遂すること です。 もう少し具体的に述べると、 AI自身が「環境」と「アクションセット」を認識し、特定の環境下でどのツールを使えばタスクを完遂することができるかを考え、行動します。 この時のAIの役割としては以下2点です ユーザーから与えられたタスクを完遂するために計画を立てる その計画通りにタスクを実行し、完了したかどうかを判断する これらを見ると、生成AI単体や、RAGで利用される場合よりも、生成AIに対してより複雑な処理が要求されることが分かります。 こういったことから、AIエージェントを構築するためには強力なAIモデルが必要であると一般的に言われています。 より具体的な理由としては以下のようなものがあげられます。 エージェントにおいて強力なモデルが求められる理由1 1つのタスクを完遂するためには、複数のステップが行われます。 そしてステップが積み重なるごとに全体の成功率も下がってしまいます。 例えば1つのステップの成功率が98%であっても、そのステップが20個連なった場合、全体の成功率としては約67%まで下がります。 この対策としては 強力なモデルを採用して、ステップ単体の成功率を上げる ステップ数を減らす といった内容が考えられます。 この1.の対策が、賢く強力なAIモデルを利用する理由となります。 エージェントにおいて強力なモデルが求められる理由2 AIエージェントはアクションを行うことで、外部にも影響を及ぼします。 例えばデータベースへのアクセスや、外部へのメール送信などを行うことができます。 想定通りの処理を行ってくれればいいのですが、想定しない処理を行われる可能性もあります。 例えば意図しないデータの書き換えや、誤った情報の外部へのメール送信などが該当します。 こういった誤った操作を行わないためにも、より賢い強力なモデルが必要となります。 AIエージェントの性能を決定づける要因 次に「良いAIエージェント」とは、どういったものを指すかについて考えてみたいと思います。 AIエージェントの性能を決定づける主な要因が以下2つです。 ツール プランニング ツール ツールはAIエージェントが利用できる道具です。 そしてこのツールは以下の3つの種類に大別できます。 知識の拡張ツール 機能拡張ツール エージェントが環境に応じて動作できるようにするツール これらのツールが豊富されている場合、生成AIが計画を行う際の選択肢が広がります。 知識の拡張ツール 1つ目が知識の拡張ツールです。 これは生成AIの知識を拡張するためのもので、本来生成AIのモデルが知りえない情報などを補完する際に利用されます。 具体的には以下のようなツールが該当します。 インターネットでの検索 データベースの検索 お気づきかもしれませんが、知識の拡張ツールを利用する点ではRAGと類似しています。 ただし、AIエージェントは取得した情報を基に自律的に行動計画を立て、複数のアクションを実行できる点でRAGとは異なります。 非常に簡素な形で実装してあるAIエージェントを、RAGとみなすことができる…とはいえるかもしれないです。 機能拡張ツール 2つ目が拡張機能ツールです。 以下のようなツールが該当します。 計算 単位変換 「計算などは生成AI単体でもできるのでは?」と思われるかもしれません。 生成AIは基本的な算数計算は可能ですが、複雑な数値計算や高精度な計算においては限界があります。 これは、生成AIが学習データのパターンから推論を行うため、計算専用ツールのような正確性は保証されないためです。 特に大きな数値や複雑な数式、統計計算などでは外部の計算ツールを使用する必要があります。 動作ツール 3つ目が動作ツールです。 以下のようなツールが該当します。 データベースの更新 電子メールの送信 これが一番のAIエージェントの醍醐味である一方で、リスクも伴うツールになります。 先ほども少し言及しましたが、外部に影響を与えることで得られる恩恵が多い一方で、誤動作などによるリスクは見逃すことができません。 プランニング 次に、性能を決定づける要素の2つ目である「プランニング」についてご紹介します。 プランニング とは、AIエージェントが与えられたタスクに対して、どのような処理を行えばタスクを完遂できるかを検討し、計画を立てることを指します。 例えば 「大手ECサイトで、人気スポーツブランド『サイオス』のTシャツのうち、現在セール価格になっているものを探してください」 というタスクが与えられたとします。 この時、AIエージェントは少なくとも2つの計画を立てることが考えられます。 計画1 ECサイトで開催中のセール対象商品をすべてリストアップする。 その膨大なリストの中から、ブランドが「サイオス」のものを絞り込む。 さらにその中から、商品カテゴリが「Tシャツ」であるものを探す。 計画2 ECサイトで、ブランドが「サイオス」のTシャツをすべてリストアップする。 そのリストアップした商品それぞれが、現在セール価格になっているかを確認する。 この2つの計画を比較してみましょう。 ECサイト全体のセール対象商品は、キャンペーンの規模によっては数十万〜数百万点にも及ぶ可能性があります。 計画1では、まずこの膨大なデータを取得してから絞り込むため、非常に多くの情報を処理する必要があり、時間もかかってしまいます。 一方で計画2は、最初に比較的母数の少ない「『サイオス』のTシャツ」という条件で商品を絞り込みます。 これなら対象は多くても数百点程度でしょう。 その上で、各商品がセール対象かどうかをチェックする方が、はるかに効率的にタスクを完了できそうです。 このように、同じゴールにたどり着く場合でも、より効率の良い計画を立てられるかどうかで、処理時間やコストが大きく変わってきます。 そして、どうしたらより良い計画が立てられるかについては、先ほども少し言及しましたが、状況を的確に判断できる性能の良いLLMモデルを利用することが一番の近道かと思います。 上記で説明したように、どのようなツールが用意されており、どのような計画が立てられるかで、与えられたタスクが正しく完遂されるかが決定されます。 ツールを豊富に用意したところで、正しく計画できなければタスクは完遂できません 正しい計画が行えたとしても、ツールが不足していればタスクが完遂できません そのため、AIエージェントに対して、 適切なツールを与え、適切な計画を立てさせること が良いAIエージェントを構築する上で重要となります。 フィードバック これまでご紹介したように、AIエージェントは与えられた「ツール」を利用して、「プランニング」を実行し、タスクを完遂しようとします。 ただ、ここでさらに注目するべきポイントが、AIエージェントが単に計画を立てて、実行するだけにとどまらない点です。 AIエージェントは自ら立てたプランを評価し、問題なければそれに従いタスクを実行していきます。 この時、もし計画に問題がある(タスクを完遂できなさそう)場合は、再度計画を練り直します。 更に、そのプランの実行中および実行後に実行結果を評価し、問題があるようであれば再度プランニングから行います。 具体的な流れは以下のようになります。 ユーザーからの要求を分解して、解決するための一連のタスク(=プラン)に分解する 生成したプランを評価する プランが適切でない場合は再生成する 生成されたプランを実行する 実行された結果を判定し、完了していない場合は再度計画し直す このフィードバックループにより、AIエージェントは失敗から学習し、より効果的な解決策を見つけることができます。 以下に参考にした記事の、非常に分かりやすい図を掲載しておきます。 (引用:https://huyenchip.com/2025/01/07/agents.html) まとめ 今回はAIエージェントについて初心に帰り、基礎的な部分のご紹介をしました。 近年、様々なAIエージェント開発ツールや、MCP(Model Context Protocol)などの登場によりAIエージェントの開発が非常に容易なものとなってきています。 その一方で、今回ご紹介したようなAIエージェントの基礎的な部分も抑えておく必要はあるかと思うので、是非参考にしていただければと思います。 ではまた! 参考 https://huyenchip.com/2025/01/07/agents.html ご覧いただきありがとうございます! この投稿はお役に立ちましたか? 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post AIエージェントとは?~基礎から理解する流行りのAIエージェント~ first appeared on SIOS Tech. Lab .
挨拶 ども!登壇資料の準備が佳境を迎えています、龍ちゃんです。資料の前段でブログを書こうと思ったら、執筆済みのブログが5件ほど積み上がっているという魔境のような現状があります。 さて今回は、その中の1つシリーズである「タイトルとメタディスクリプションをAIに丸投げしてみた」というブログの内容になります。 SEOわからん勢のリアルな悩み ブログを書き終わった後に悩む要素って、サムネイルとタイトルとメタディスクリプションですよね。正直、タイトルとメタディスクリプションだけで考えるのは非常に疲れてしまいます。というか嫌ですね。 だってメタディスクリプションって何なんですか?知らないですよね。でもやっぱりタイトルの引きってあると思うんですよね。「検索されやすいタイトルを…」って言われても困っちゃいますよね。 というわけで、そういうめんどくさい作業をAIに丸投げしちゃおうぜ!という話になります。 こんなことで悩んでませんか? タイトル考えるのに30分かかる問題 メタディスクリプションって何?状態 キーワードとか意味不明 「検索されやすいタイトルを…」とか言われても困る 結論:もうAIに丸投げしよう 実際にやってるタイトル生成の流れ もう今では、タイトルやメタディスクリプションを自分で考えることなんて1個もなくなりました。AIが出してきたものに対して文句を言ってるだけで完成するんですね。 具体的な流れとしては、まずブログを執筆します。これは避けることのできない工程です。ブログを執筆して、そのブログを入力として与えます。 ステップ1:記事の要素を整理 使った技術スタック 想定読者(初心者?上級者?) 記事で解決する問題 他の記事との違い ステップ2:Claudeに投げるプロンプト あなたは、SEOに精通したライターです。 Goal:ブログ用タイトル・メタディスクリプションの作成 Plan: - 添付ファイルからコンテンツの把握 - タイトルを55~60文字以内で考案 - メタディスクリプションを85文字以内で作成 - SEO的に優れているという観点で順位付け - 複数案を提案 Tips: - 誇大広告は避けてください - 技術名を明確に含める - 実践的な価値を伝える ステップ3:複数案もらって選ぶ だいたい3-5個案をもらう 自分が「あ、これ読みたい」と思うやつを選ぶ 技術名が入ってるかチェック メタディスクリプション生成の流れ メタディスクリプションも同様の方法で作成することができます。ですが、メタディスクリプションはプロジェクトナレッジの追加を行い、条件付けを行っています。 SEOなんもわからんから調査してみた メタディスクリプションって何なんですか?正直全然わからなかったんですよね。 「120文字以内で書け」とか「160文字がベスト」とか、色んな情報が飛び交ってて何が正解かわからない状態でした。タイトルはなんとなく「キャッチーに書けばいいんでしょ?」って感じでしたが、メタディスクリプションは本当に謎。 そこで、SEOなんもわからん勢の僕が取った行動は「AIに調査してもらう」でした。調査はClaude リサーチとGemini DeepReserchを利用して調査しました。 調査結果をプロジェクトナレッジに登録 この調査結果を「メタディスクリプションガイド」としてプロジェクトナレッジに登録しました。 登録した重要な発見 : 文字数の現実 :60-85文字が2025年の実際の表示限界 表示確率の現実 :Googleが設定内容を使うのは28%だけ スマホファースト :検索の75%がスマホなので、スマホ基準で考える 前半50文字ルール :重要情報は絶対に前半に配置 この調査をやってみて「やっぱりSEOって奥が深いんだな」って思いました。でも同時に「AIに調査してもらえば、素人でもプロレベルの知識が手に入る」っていうことも分かりました。 ナレッジベースを活用したプロンプト完成版 プロジェクトナレッジに調査結果を登録したので、今度はそれを活用したプロンプトを作成しました: あなたは、SEOに精通したライターです。 Goal:ブログ用メタディスクリプションの作成 制約条件(プロジェクトナレッジより): - 文字数:60-85文字以内(2025年現在の実際の表示限界) - プライマリキーワード:最初の50文字以内に必ず配置 - 技術名を2-3個まで(キーワード詰め込み禁止) - 誇大表現禁止(「完全ガイド」「決定版」など) - スマホ表示を最優先に考える Plan: 1. 添付ファイルからコンテンツとタイトルの把握 2. プロジェクトナレッジのメタディスクリプション評価指標を参照 3. 前半50文字に最重要情報を配置したメタディスクリプションを複数考案 4. SEO的に最適かどうかの観点で順位付け 5. 最終的に一つに絞って推奨案を提示 Tips: - プロジェクトナレッジの制限事項を厳守 - 価値提案を明確にする(読者のメリット明示) - 技術レベルを表示する(初心者向け/上級者向け) - 問題解決フォーカスで書く ポイント :「プロジェクトナレッジより」「プロジェクトナレッジの制限事項を厳守」って入れることで、Claudeが調査結果を参照してくれるんです。これがめちゃくちゃ便利! 実例:劇的ビフォーアフター Claude暴走制御記事の場合 元々考えてたタイトル :「Claudeの暴走制御を行う3つのパターン」 Claudeが作ったタイトル :「 Claude調教術|暴走パターンを制御する3つのプロンプトテクニック 」 メタディスクリプション :「Claude制御の実践ガイド。過剰Artifact生成・スレッド肥大化・人間主導学習の3テクニックをプロンプトエンジニアリング視点で解説。Goal設定や成果物否定、段階的学習法で効率的AI活用を実現」 結果 :技術名が明確で検索されやすそう! 2025-07-04 Claude調教術|暴走パターンを制御する3つのプロンプトテクニック Azure + Next.js記事の場合 元々考えてたタイトル :「Azure SWA×Managed Fucntions:Next.jsでBicepから作成してGitHub Actionsでデプロイする」 Claudeが作ったタイトル :「 Azure SWA×Next.js認証API統合を実践解説【DevContainer〜本番まで】 」 メタディスクリプション :「Azure SWAでNext.js×Azure Functions認証API統合を実践解説。DevContainer開発環境からBicep IaC、GitHub Actions並列ビルドまで完全対応。Standard プラン対応でセキュアな認証フロー構築」 結果 :具体的で差別化されたタイトルに変身! 2025-07-07 Azure SWA×Next.js認証API統合を実践解説【DevContainer〜本番まで】 やってみてわかったコツと注意点 誇大表現問題への対処法 実際に僕がぶち当たった問題なんですけど、Claudeって「完全ガイド」とか「決定版」とか誇大表現が好きなんですよね。 そんな自信持ってブログ書いてるわけないじゃないですか!なので、そういった時は「ブログは完全版に耐えることができる内容ですか?」って聞いちゃうんです。すると反省して「完全じゃないです」って言って「実践編」とかに変えてくれます。 プロンプトで指定すべきこと 技術レベル(初心者向けとか) 記事の種類(チュートリアル、解説、比較など) 使ってる技術名 文字数制限 人間が最終チェックすべきポイント 内容と合ってるか 誇大広告になってないか 技術名が正確に記載されているか 自然な日本語になってるか SEO効果は実際どうなった? SEO効果ってところは、これ測ってないんで知らないんですよね(笑) ただ、なんとなく昔のブログのタイトルと今のブログのタイトルを比較して、なんかいい感じです。なんか技術ブログっぽくなってるんですよ。てか昔のタイトルがゴミすぎるって説はあるんですけど。 時間的な効果は確実 :タイトル考えるのに1時間かかってたのが、プロンプト入力だけなので5分になりました。めっちゃ早い! 主観的な変化 タイトル考える時間が激減(1時間→5分) 記事を書くこと自体に集中できるように なんとなく「それっぽい」技術ブログタイトルになった ストレスが大幅に軽減された まとめ:SEOわからなくてもなんとかなる 今回は、SEOなんもわからん勢の僕が「タイトルとメタディスクリプションをAIに丸投げしてみた」という話をしてきました。 やったこと : Claudeに調査してもらってプロジェクトナレッジに蓄積 プロンプトを作ってタイトル・メタディスクリプション生成を自動化 人間は最終チェックだけ 得られた成果 : タイトル考える時間が1時間→5分に激減 なんとなく技術ブログっぽいタイトルになった ストレス大幅軽減でブログ執筆に集中できるように 正直、SEO効果のほどは測ってないので分からないんですが、少なくとも「タイトル考えるのめんどくさい問題」は完全に解決しました。 皆さんも、ブログのタイトルやメタディスクリプションで悩んでる時間があったら、その時間をブログの内容充実に使った方が絶対いいですよね。AIにできることはAIに任せて、人間は創造的な部分に集中しましょう! それでは、また次回の記事でお会いしましょう〜! ご覧いただきありがとうございます! この投稿はお役に立ちましたか? 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post SEOなんもわからんけんClaudeに丸投げしたらストレスフリーになった話 first appeared on SIOS Tech. Lab .
挨拶 ども!Claudeでブログを書きまくっている龍ちゃんです。最近はClaudeのおかげでブログ執筆のスピードがメキメキと上がってきましたが、一方で作業時間の捻出に苦労している今日この頃です。 今回はClaudeでMermaidの図をサクッと作ってもらう方法について解説していきます。皆さんも技術ブログで「図があったらもっと分かりやすいのに…」と思ったことはありませんか? なぜMermaidなのか? 技術ブログにおける図解の重要性 技術ブログで図解が重要な理由は明確です。図があるかないかで読者の理解度や説得力が大きく変わります。ビジュアル的な要素があると、コンテンツの分かりやすさが飛躍的に向上するからです。 しかし、図を作るのがとにかく大変です。私もブログを書いた後にFigmaで図を作ることがありますが、2時間くらいかかってしまいます。作るのは楽しいのですが、やはり時間がかかるのがネックです。特にシーケンス図やフローチャートを説明する時は、図があった方が確実に分かりやすいのですが、作成の手間を考えると躊躇してしまいがちです。 Mermaidが解決する課題 そこで登場するのがMermaidです。Mermaidを使うと、以下のようなメリットがあります: コードベースで図を作成 :テキストで書けるのでClaudeが得意 短時間で完成 :5-10分程度で作成可能 一定の品質を保証 :自由度が限定されているため、意図しない結果になりにくい メンテナンスが容易 :コードなので後から修正しやすい この記事で身につくスキル この記事を読むことで、以下のスキルが身につきます: Claudeで効率的にMermaidコードを生成する方法 作成したMermaidを保存・管理するワークフロー Live Editorを活用した細かい調整テクニック 従来のツールでは2時間かかっていた図作成が、この方法なら5-10分で完了します。シリーズの一環として、ぜひ最後まで読んでみてください。 基本的な作業フロー 全体の流れ Claude × Mermaid × Live Editorを使った図作成の基本フローは以下の通りです: 要求定義(作りたい図の整理) Claudeにプロンプト入力 Mermaidコード生成 Live Editorで確認・調整 PNG/SVGで保存・活用 Live Editorとは Mermaid Live Editor は、ブラウザ上でMermaidコードをリアルタイムに編集・プレビューできる公式ツールです。コードを入力すると即座に図が表示され、エラーチェックも自動で行ってくれます。 効果的なプロンプトの構成要素 Claudeに良いMermaid図を作ってもらうためのプロンプトには、以下の要素を含めましょう: 図の種類 :フローチャート、シーケンス図、パイチャートなど 目的 :何を説明したいのか 要素 :含めたい項目やステップ 制約条件 :文字数制限や特別な要求があれば 実践①:フローチャート作成術 フローチャートが適している場面 フローチャートは以下のような場面で威力を発揮します: 業務プロセスの可視化 :人間の判断や作業手順 システムの処理流れ :API処理やデータ変換の流れ 意思決定プロセス :条件分岐を含む判断フロー 重要なのは、複雑すぎる分岐は避けることです。2-3分岐程度に収めると見やすい図になります。 実際のプロンプト例 Mermaid形式のフローチャートで以下のブログ執筆プロセスを表現してください: 1. 執筆:人間による初稿作成 2. AI校閲:Claudeによる文体・技術的チェック 3. 評価:E-E-A-T観点での点数化 4. 改善判定:70点以上なら公開、未満なら修正 5. 修正:評価結果に基づく改善作業 6. 再評価:改善効果の測定 7. 公開:最終版の公開 見やすさを重視し、判定部分を分岐で表現してください。 よく使うパターン集 API処理フロー リクエスト受信 → 認証チェック → 処理実行 → レスポンス返却 デプロイフロー コード更新 → テスト実行 → ビルド → デプロイ → 監視開始 バグ修正プロセス バグ報告 → 現象調査 → 原因特定 → 修正実装 → テスト → リリース 実践②:シーケンス図でAPI解説 シーケンス図の特徴 シーケンス図は時系列での処理を表現するのに最適です。特に以下のような場面で効果的: システム間通信 :API呼び出しやデータのやり取り 認証フロー :OAuth2.0やJWT認証の流れ マイクロサービス連携 :複数サービス間の協調処理 実際のプロンプト例 以下の要件でMermaidのシーケンス図を作成してください: 【参加者】 - ユーザー - フロントエンド - 認証層 - バックエンド - Google Sheets - Azure OpenAI 【処理フロー】 1. ユーザーがフロントエンドにデータ分析を要求 2. フロントエンドが認証層で認証確認 3. 認証OKでバックエンドにAPI呼び出し 4. バックエンドがGoogle Sheetsからデータ取得 5. バックエンドがAzure OpenAIにAI処理要求 6. Azure OpenAIで「Agent Systemとして処理」(注釈追加) 7. 分析結果をバックエンド経由でフロントエンドに返却 8. ユーザーに結果表示 エラーケースも含めて表現してください。 プロンプトのコツ 参加者を明確に定義する :Claudeに推測させると意図と異なる結果になりがちです。関連するシステムやユーザーを明確に列挙しましょう。 処理順序を番号付きで説明 :時系列が重要なので、ステップを明確に番号付けすると精度が上がります。 実践③:パイチャートで割合を可視化 パイチャートの活用場面 パイチャートは割合や構成比を表現する際に効果的です: リソース使用量 :メモリ、CPU、ストレージの使用率 コスト内訳 :プロジェクト予算の配分 技術スタック構成 :使用技術の割合 特にこちらは、SVGで出力してFigmaで活用したりしています! 実際のプロンプト例 MermaidでPieチャートを作成してください。 【タイトル】 ブログ記事のトークン使用量内訳 【データ】 HTMLタグ:6000 記事本文:12000 プロンプト:2200 その他:1600 各要素の割合を%で表示してください。 注意点 パイチャートは要素が多すぎると見にくくなります。5-7要素程度に収めて、小さな項目は「その他」でまとめるのが効果的です。 トラブルシューティング よくある問題と解決法 構文エラーが発生する場合 Claude側での確認 :まずClaude上で図が表示されるかチェック Live Editorでの検証 :エラー箇所を具体的に特定 Claudeに修正依頼 :エラーコードをそのまま貼り付けて「修正してください」と依頼 日本語表示がうまくいかない場合 英語で作成 :最初は英語で図を作成 後から翻訳 :完成後に日本語に変換 エンコーディング確認 :文字化けの場合はUTF-8で保存 図が複雑になりすぎる場合 階層化 :大きな図を複数の小さな図に分割 抽象度調整 :詳細すぎる部分を簡略化 別の図形式 :フローチャートではなくシーケンス図に変更 すぐ使えるプロンプトテンプレート集 Claudeに図形式を確認する Mermaidで作成可能な図の種類を、簡単なサンプルコード付きで教えてください。 基本テンプレート フローチャート用 [システム名/プロセス名]をMermaidフローチャートで作成してください: 【処理ステップ】 - ステップ1:[具体的内容] - ステップ2:[具体的内容] - 判定:[条件分岐の内容] 見やすさを重視し、エラーハンドリングを含めてください。 シーケンス図用 [システム名]の処理をMermaidシーケンス図で表現してください: 【参加者】 [A、B、C...] 【処理フロー】 1. [A→Bの処理内容] 2. [B→Cの処理内容] ... エラーケースも含めて表現してください。 パイチャート用 以下のデータでMermaidパイチャートを作成してください: 【タイトル】 [グラフのタイトル] 【データ】 項目1:[数値] 項目2:[数値] ... 割合を%表示で含めてください。 修正依頼用テンプレート 先ほどのMermaid図を以下の点で修正してください: 【修正内容】 - [修正点1] - [修正点2] - [修正点3] より分かりやすく調整してください。 Live Mermaid Editorの活用術 Live Editorの優位性 Live Mermaid Editorが他のツールより優れている点: リアルタイム編集 :コードを書くと即座に図が更新される 構文エラーの即座検出 :エラー箇所をリアルタイムで表示 フル機能対応 :GitHubやNotionで制限される機能も利用可能 ブラウザ完結 :インストール不要で、どこでも利用可能 URL共有 :作成した図をURLで簡単に共有できる テーマ選択 :GitHub、Dark、Neutralなど複数のテーマ 他のプラットフォームとの違い NotionやGitHub上でもMermaidは表示されますが、以下の制約があります: Notion : コードブロックのサイズ制限により大きな図が見にくい コードまたは図のみの表示選択は可能だが、同時編集・確認は困難 GitHub : 一部のMermaid機能に制限(ハイパーリンク、ツールチップ、特定シンボル等) 保存後に図が表示されるため、試行錯誤に時間がかかる 構文エラーの詳細が分かりにくい Live Editor : 複雑な図を作成する際の微調整が効率的 全Mermaid機能を制限なく利用可能 リアルタイムでエラー確認・修正が可能 ファイル管理・履歴機能 Live Editorの保存・管理機能: 自動履歴保存 : 編集内容を1分間隔で自動保存 最大30編集まで履歴を保持 ブラウザストレージに依存(データクリア時は消失) 外部保存機能 : GitHub Gistとの連携による長期保存 URL共有によるチーム間でのやり取り 手動保存による重要バージョンの固定 制限事項 : 履歴はブラウザローカルに保存されるため、他デバイスでは参照不可 ブラウザデータをクリアすると履歴が失われる 長期保管にはGist連携の活用を推奨 まとめ 今回は、ClaudeとMermaidを組み合わせた効率的な図作成方法について詳しく解説しました。 この記事のポイント 時短効果 :2時間の作業が5-10分に短縮 品質確保 :一定レベルの見やすい図を安定して作成 学習コスト低 :複雑なツールの習得が不要 メンテナンス性 :コードベースなので修正が容易 Live Mermaid Editorとの組み合わせにより、リアルタイムでの編集・確認も可能になります。技術ブログの図解作成で時間を短縮したい方は、ぜひこの方法を試してみてください。 図があるだけで記事の分かりやすさが劇的に向上します。皆さんも、ぜひMermaidを使った図解作成にチャレンジしてみてください! ご覧いただきありがとうございます! この投稿はお役に立ちましたか? 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post ClaudeでMermaid図作成を自動化!2時間→5分の劇的時短術【Live Editor活用】 first appeared on SIOS Tech. Lab .
はじめに ども!最近、Claude Proになってより一層Claudeを使い倒している龍ちゃんです。新しい技術ということもあり、書くことがいっぱいあって楽しいですね。あと、書き手があと3人ほどいたら嬉しいところです。弊社でも徐々にClaude関連の記事が増えていて、僕的にはウハウハな状況です。 さて、今回は以前書いた「 Claude×技術ブログで執筆環境が激変!次世代AI協働ワークフロー解説 」で取り扱っていなかった 詳細なプロンプト技術 について、深掘りして解説していきたいと思います。 最終的には登壇資料としてまとめなきゃいけないので、これから頑張ってブログを書いていくしかないですね。それでは、始めていきましょう! シリーズ全体構想 まだ第1回を読んでいない方は、ぜひ第1回を読んでいただけると幸いです。シリーズの全体構想は以下のとおりです: 第1回: Claude×技術ブログで執筆環境が激変!次世代AI協働ワークフロー解説 第2回:Claude技術ブログ品質を10倍向上させる3段階チェック術【プロンプト実践】 ← 今回はここ! 第3回:構成・アウトライン編 第4回:SEO最適化編 第5回:ビジュアル制作編 第6回:サムネイル・デザイン編 AIを活用した3段階品質チェック戦略 品質チェックという部分に注目して、Claudeをどう使っているのかについて解説していきます。ここで取り扱う内容は主に以下の3つになります: 文体統一 技術的正確性の検証 アウトライン評価 文体統一の実践手法 自分の文体を抽出してシステムプロンプト化 文体統一では、まず自分の文体の癖を抽出するところから始めます。具体的には過去に書いたブログ記事をClaudeに入力として与え、共通する文体の特徴や全体感を抽出しています。 出力されたシステムプロンプトの一部をご紹介します: # SIOSテックブログ風文体・テイスト再現プロンプト 以下の文体・テイストでテクニカルブログを執筆してください: ## 基本的な文体・トーン - **親しみやすくカジュアルな表現**: 「ども!」「〜ですね」などの親近感ある表現 - **個人的な体験談を交える**: 執筆者の個人的な近況や体験を自然に織り込む - **軽快でカジュアルながら技術的**: 難しい技術内容も親しみやすく説明 ## 記事構成のテンプレート 1. **はじめに** - 個人的な近況(AI課金額、技術動向など) - 今回のトピック紹介 - 読者へのメリット提示 2. **技術解説部** - **段階的な説明**: 基礎から応用まで順序立てて解説 - **豊富なコード例**: 実際のコードを多用し、コメントで詳細に説明 [...](詳細なプロンプトは省略) 自分のブログから抽出された内容なので、「あ、自分って意外とこういう書き方の癖があるんだな」と気づくことができて結構面白いですね。出力されたシステムプロンプトは、間違っている部分を修正してClaudeのプロジェクトナレッジとして登録しています。 Claude暴走防止のプロンプト設計 実際に起きた問題として、ブログのアウトラインと部分的な章構成を与えた場合、Claudeが勝手にブログ全体を書いてしまうということが発生しました。 今回のターゲットは、ブログをAIに生成してもらうことではなく、 人間が書いたブログをClaudeに修正してもらう という使い方です。そのため、追加でプロジェクトナレッジのシステムプロンプトとして以下のようなプロンプトを入力しています: プロジェクトナレッジを検索して使えそうな情報がある場合は、使用してください。 情報を作成をする前に具体的なプランを明示して許可を取ってから実行をしてください。 明確な指示がない場合は、文章の校閲をしてほしいと解釈してください。 ブログ全文の生成は「ブログの全部を書いてほしい」という明確な指示があった時だけです。 この辺のテクニックに関しては、「 Claude調教術|暴走パターンを制御する3つのプロンプトテクニック 」で詳しく取り扱っています。 入力方法と注意点 与える入力は、アウトラインと執筆した章単位で分割しています。こうすることで、部分的にアウトプットを作成しながら章を追加したい場合、アーティファクトを追加するという形で出力されます。 トラブルシューティング として気をつけているポイント: PDFでの入力 : 読み込みに失敗する可能性があるため避ける 画像URL含有 : 文章中に画像のURLが含まれている場合、参照できずに出力が失敗することがある アウトライン共有 : 全体像を把握させるため、必ずアウトラインを共有する これらの問題を避けるため、入力は極力 テキストベース で行っています。 技術的正確性の検証アプローチ 公式リファレンスとの照合手法 技術的正確性の検証では、すでに執筆したブログの正確性を確認する作業を行っています。こちらのブログ「 【実践解説】技術ブログ品質チェック術|Gemini Deep Researchで5分検証 」では、執筆済みのブログを入力として与え、ブログの評価を行うという手法で検証しています。 このアプローチは、 ブログの執筆完了後ではなく、執筆中に検証を行う ものです。 大前提として、AIに聞いたところで、必ずしも正確な情報が返ってくるわけではありません。ただ、入力として公式リファレンスのURLと書いてある内容の精度という観点においては優秀な精度を誇っています。 具体的な検証プロセス 一次情報として人間が書いたブログと、参照した公式リファレンスを合わせて与えることによって、「ブログで書かれているコンテンツと公式情報に矛盾がないか?」という確認を主に行っています。 また、入力として追加で執筆したブログのコンテンツに関する言及があるかどうかを聞くことによって、自分が見落としていた問題などを発見することができます。 着眼点としては : 公式が推奨するベストプラクティスに則っているか 最新の仕様変更に対応できているか 誤解を招きやすい表現がないか リアルタイム検証の実践手法 このアプローチは、ブログの執筆完了後ではなく、執筆中に検証を行うものです。章を書き終えるたびに即座に検証することで、後から大幅な修正が必要になるリスクを回避できます。 実際に使用しているプロンプト ブログの章を執筆しました。引用されているURLの内容と執筆されている内容に齟齬がないか確認をお願いします。引用されている情報をもとに判断して、推測などを含めないでください。 ~~ブログコンテンツ~~ アウトライン評価の実践 対話的なアウトライン構築 アウトライン評価は、執筆前の段階の整備作業となります。アウトラインについては、AIと対話的に作成することもあります。主にClaudeとの対話を通じて構築することもあれば、人間がベースを作成してAIに入力して評価してもらうこともあります。 使い方の流れ : ざっくりと章だけを書く そのアウトラインを特定のプロンプトで評価してもらう 評価の返答を参考にして、章立ての追加やアウトラインの拡充を行う 再評価を繰り返すことによって、ブログの品質を向上させる 私の体感ですが、この方法でブログを書く順序として非常に効果的です。 トラブルシューティングと改善ポイント よくある問題 : アウトラインで章タイトルのみを記載している場合、AIが想像する内容の方向性が自分の考えている方向性と異なることがある 解決方法 : アウトライン内に内容の概要を箇条書きで追加する 「10段階評価でお願いします」というリクエストを加えて、明確な数値化を実現する 「計画を出力してください」というリクエストを加えて、一度出力形式の確認をする アウトライン評価のサンプルプロンプト あなたはSEOが得意な技術ライターです。 最新リソースからブログのアウトラインをEEAT・トレンド性の観点から評価をしてください。 検索などを駆使して再帰的に反復して時間をかけて結論を出してください。 アウトラインは以下です 【Claude実践】技術ブログ品質を10倍向上させる対話型チェック術 1. はじめに * AIによる技術ブログ執筆支援の現状 * 品質向上における課題 * この記事で得られるもの [...](詳細なアウトラインは省略) この評価手法には、GeminiのDeep ResearchやClaude Searchなども活用できますが、ClaudeのWeb検索機能でも問題なく動作すると考えています。 実際の評価結果と改善プロセス 実際にこのプロンプトを使用した結果、以下のような評価を得ることができました: E-E-A-T評価スコア例 : Experience : 8.2/10(具体的な体験談が豊富) Expertise : 8.7/10(技術的深度と最新動向への言及) Authoritativeness : 8.0/10(シリーズとしての一貫性) Trustworthiness : 8.6/10(限界や課題の率直な共有) トレンド性評価 : 9.0/10(2025年のAI活用トレンドに合致) この評価を基に、Experience部分により具体的な失敗例を追加し、Trustworthiness向上のために検証中の内容を明示するなど、継続的な改善を行っています。 効率化の実測と品質管理手法 データ駆動型の品質向上アプローチ 体感値だけでなく、より客観的な品質管理を実現するため、以下の指標で継続的に測定を行っています: 執筆効率の定量化 : 従来手法 : 2時間(体感値) AI協働手法 : 30分(体感値) 効率化率 : 約75%向上 品質指標の数値化 : E-E-A-T総合スコア : 8.5/10(第三者評価による) 反復改善のフィードバックループ 実際の運用では、以下のサイクルで品質向上を図っています: 執筆 : 人間による初稿作成 AI校閲 : Claude による文体・技術的チェック 評価 : E-E-A-T観点での点数化 改善 : 評価結果に基づく修正 再評価 : 改善効果の測定 このプロセスを繰り返すことで、継続的な品質向上を実現しています。 トラブルシューティングのポイント 図表関連の対応 技術ブログでは図表が重要な要素となりますが、以下の点に注意が必要です: PNG/JPEG/SVG : それぞれの特性を理解した使い分け Mermaidの活用 : システム構成図やフローチャートの効率的な作成 図のクラッシュ対応 : ファイルサイズや解像度の最適化 想定される技術的課題 入力データの制限 : ファイルサイズの上限 対応フォーマットの制限 処理時間の制約 出力品質の安定化 : プロンプトの一貫性確保 期待する出力形式の明確化 エラーハンドリングの仕組み作り 実践的な課題解決事例 実際の運用で直面した課題と解決策をご紹介します: 課題1: AI暴走の制御 問題 : アウトライン提示時にブログ全体を勝手に生成 解決策 : システムプロンプトでの明確な役割制限 課題2: 文体の一貫性維持 問題 : 章ごとに文体が変化してしまう 解決策 : 過去記事からの文体抽出とナレッジ化 課題3: 技術情報の正確性確保 問題 : AI による誤った技術情報の生成 解決策 : 公式リファレンスとの照合プロセス導入 課題4: 図が含まれることによりクラッシュ 問題 : 入力に図が含まれる場合にクラッシュする 解決策 : 図を無視するようにプロンプトで無視(マスクする) Notion MCP連携の実装成果 期待から実現へ ClaudeとNotionの連携について検討していた Notion MCP ですが、実際に実装に成功しました!当初は「絶賛検証中」としていましたが、想定以上にスムーズな統合を実現できています。 「 Claude×Notion MCP実装術|コネクタ版とIntegration版の選び方解説 」で解説しています。 実装により実現できたこと : 自然言語でのページ操作 : Claude経由でのNotionページの作成・更新・検索 校閲済みコンテンツの直接保存 : ブログ校閲結果のワンクリック保存 過去記事からの文体抽出自動化 : 蓄積された記事データの効率的活用 実装で得られた知見 詳細な実装手順については別記事「 Claude Notion MCP実装ガイド 」で解説していますが、ここでは品質向上ワークフローへの統合効果をご紹介します。 効果測定結果 : 校閲結果の保存時間 : 手動2分 → 自動10秒(92%短縮) 過去記事参照 : 手動検索5分 → AI検索30秒(90%短縮) 文体抽出の精度 : 手動選別 → 全記事自動解析による包括性向上 実際の活用事例 1. リアルタイム品質チェック結果の蓄積 校閲結果をNotionのデータベースに自動保存 → 品質向上のパターン分析が可能に → よくある間違いの事前防止 2. 文体統一プロセスの自動化 過去160本の記事から文体特徴を自動抽出 → より精密なシステムプロンプト生成 → 文体一貫性の向上 3. 技術検証の効率化 Notion内の技術ナレッジベースと連携 → 過去の検証結果の瞬時参照 → 重複検証の回避 次なる挑戦:音声認識ワークフロー Notion MCP連携が実現できたことで、次のステップとして 音声認識機能 を活用したNotion直接入力の検証を進めています。 想定ワークフロー : 音声入力 : Notionに話した内容を直接テキスト化 AI校正 : Notion AI×Claudeによる文章整理と構成最適化 品質チェック : 今回紹介した3段階チェックの自動実行 最終出力 : 投稿済み品質のブログ記事の完成 期待される効果 : 執筆時間 : 現在30分 → 10分程度(70%さらなる短縮) アイデアキャプチャ : 思いついたタイミングでの即座記録 ハンズフリー執筆 : 移動中や休憩時間の有効活用 効率化の実測データと検証 ただし、ブログ執筆にかかる時間については具体的な数字を測定していなかったので、これはあくまで体感値です。より正確な効果測定のために、以下の指標で検証を進めています: 執筆時間 : 初稿完成までの時間 校閲回数 : AI支援による修正回数 品質スコア : E-E-A-T観点での評価値 読者エンゲージメント : 実際の記事への反応 まとめ 今回は「Claude×技術ブログ品質向上編」として、AIを活用した3段階品質チェック手法について詳しく見てきました。 3つの実践手法 : 文体統一 : 過去記事からの文体抽出とシステムプロンプト化によるClaude暴走防止 技術的正確性 : 公式リファレンスとの照合による執筆中のリアルタイム検証 アウトライン評価 : E-E-A-T観点での対話的評価と継続的改善 また、将来的な展望として、Notion MCP連携や音声認識を活用した執筆フローの可能性についても触れました。実際の運用では、効率化だけでなく品質管理の数値化や反復改善のフィードバックループが重要であることも確認できました。 次回の「構成・アウトライン編」では、より詳細な企画段階でのClaude活用術をお届けする予定です。お楽しみに! ご覧いただきありがとうございます! この投稿はお役に立ちましたか? 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude技術ブログ品質向上の試行錯誤|3段階チェックで安定【プロンプト実践】 first appeared on SIOS Tech. Lab .
はじめに ども!最近Claude ProでAI開発にどっぷりハマっている龍ちゃんです。先日、Claudeにブログ記事を評価してもらったら「2025年としてはこのブログ普通っすね!むしろ遅れてるぐらいっす」って辛辣なコメントをもらっちゃいました。一方で、Gemini Deep Researchで同じ記事を評価したらべた褒めだったので、AIによる評価の違いって面白いですよね。 今回は、いよいよClaude DesktopとNotion MCPを接続して、AIによるドキュメント自動操作環境を構築していきます。 予測される効果として、「 Claude×技術ブログで執筆環境が激変!次世代AI協働ワークフロー解説 」こちらのブログで解説している内容がよりグレードアップされると期待しています。 事前準備:Node.js環境のセットアップ まずは、Notion MCPサーバーを動作させるためのNode.js環境を準備しましょう。既にNode.jsが入っている方は、バージョン確認から始めてください。 Node.js未インストールの場合:Voltaで管理 Node.jsが入っていない方には、 Volta での管理をおすすめします(完全に個人的な趣味ですが…)。お好きな管理ツールを使っていただいて構いません。 Voltaのインストール(Windows) # 管理者権限で実行 curl https://get.volta.sh | bash Node.jsのインストール # LTS版をインストール volta install node # バージョン確認 node --version npm --version 既存環境の確認 Node.js v18以上が必要です。以下のコマンドで確認してください: # Command PromptまたはPowerShellで実行 node --version npm --version Notion MCPサーバーの動作確認 以下のコマンドで、Notion MCPサーバーがインストールできるかテストします: # 動作確認テスト npx -y @notionhq/notion-mcp-server --help 正常に動作すればヘルプが表示されます。Ctrl+Cでプロセスを終了してください。 接続方法の比較と選択 補足:Notion公式のHosted MCP Serverについて 2025年7月より、Notion公式がHosted MCP Serverも提供開始しました! Hosted MCP Server(リモート版)の特徴 OAuth認証でワンクリック接続 AI向けに最適化されたMarkdown形式でのデータ提供 サーバー管理不要 Notionがクラウドでホスト ワークスペース全体への完全アクセス ただし、 現在報告されている課題 : Gemini CLI等のMCPクライアントとの互換性問題 細かいアクセス制御ができない(ワークスペース全体のみ) なぜローカル実装(npx経由)を推奨するのか Notion公式のHosted MCP Serverも魅力的ですが、現在以下の理由でローカル実装をおすすめします: 方法 設定難易度 プラン制限 アクセス制御 安定性 推奨ユーザー コネクタ版(Remote) 公式未明記 ワークスペース全体 簡単設定重視 Integration版(Local) なし ページ単位 制御重視 Hosted MCP 公式未明記 ワークスペース全体 最新技術試行 全プラン対応 : 無料版でも利用可能 細かい制御 : ページ単位でアクセス権限設定 安定動作 : Node.js環境があれば確実に動作(今更感もあるけども…) カスタマイズ : 必要に応じて機能拡張可能 互換性 : 各種MCPクライアントで動作確認済み そのため、確実性と柔軟性を重視してnpx経由での実装方法をご紹介します。 方法1:Notionコネクタでの簡単接続 Claude Desktopの コネクタ機能 を使用する方法です。これはAnthropicが推奨する公式ツールで、ブラウザ上でMCP認証を簡単に完了できます。 接続手順 Claude Desktop → 設定 → コネクタ 「カスタムコネクターを追加」をクリック 「Notion」を検索・選択 自動的に認証ページが開くので、認証を完了 重要な注意点 コネクタ版では ワークスペース全体 に接続されるため、Claudeからワークスペース内のすべての情報にアクセス可能になります。機密情報が含まれる場合は、次の「Notion Integration版」をご検討ください。 トラブルシューティング MCPの接続が何度か失敗する場合は、コネクタから切断をして再度認証を行ってください。 方法2:Notion Integration作成してMCP接続 こちらの方法では、NotionのAPIを使用してMCPを構築し、アクセス権限を細かく制御できます。特定のページのみにアクセスを限定したい場合におすすめです。 こちらの方法に関しては Notion公式が記事としてまとめています 。 Integration作成 Notion Integrations にアクセス 「New integration」をクリック 以下を設定: Name : Claude MCP Integration Workspace : 使用するワークスペースを選択 Capabilities : デフォルトのまま(Read content, Update content, Insert content) Integration Token取得 作成後、「Internal Integration Secret」を取得してください。 ntn_ で始まるトークン(例: ntn_abc123def456... )が表示されます。 セキュリティ注意 このトークンは機密情報です。安全に保管し、他人と共有しないでください。 ページへのアクセス権限付与 Notionで任意のページを開く 右上の「…」メニュー → 「接続を追加」 作成したIntegrationを選択して接続 この手順により、指定したページのみにMCPからのアクセスが制限されます。 設定ファイルの場所確認 Claude Desktopから設定ファイルにアクセスする方法が最も簡単です: Claude Desktop → 設定(Settings) 開発者(Developer)タブ 「Edit Config」ボタンをクリック 参考:ファイルパス Windows: %APPDATA%\\Claude\\claude_desktop_config.json ファイルが存在しない場合は新規作成してください。 設定ファイルの作成・編集 以下の内容で設定ファイルを作成・編集します: { "mcpServers": { "notionApi": { "command": "npx", "args": [ "-y", "@notionhq/notion-mcp-server" ], "env": { "OPENAPI_MCP_HEADERS": "{\"Authorization\":\"Bearer ntn_your_token_here\",\"Notion-Version\":\"2022-06-28\"}" } } } } 重要 : ntn_your_token_here を Step 2で取得した実際のIntegration Tokenに置き換えてください。 動作確認 Claude Desktopの再起動 Claude Desktopを完全に終了(システムトレイからも終了) Claude Desktopを再起動 接続テスト Claude Desktopで以下のプロンプトを試してください: Notionのワークスペースに接続できているか確認してください。利用可能なページがあれば一覧を表示してください。 実際にページを操作してみる 「テストページ」という名前で新しいページを作成して、簡単な内容を追加してください。 成功すれば、Claude経由でNotionページが作成・編集されます! どれを選ぶべきか 実際に複数の方法を試してみて感じた違いをお話しします。 これからNotion×Claudeを始める方 : コネクタ版がおすすめ(プラン制限の詳細は公式発表を確認) 細かいアクセス制御が必要・確実性重視 : Integration版一択 開発者・他AIツールも検討中 : Integration版でMCPサーバー構築 最新技術を試したい方 : Hosted MCP Server( 互換性問題 承知の上で) 今後の展望:AIフレンドリーなNotion環境構築 現在の私のNotion環境は、残念ながらAIフレンドリーとは言えません。今後は以下の改善を検討しています: AIが効率的にアクセスできるページ構造への再編 よく使用するページの階層浅化 AI専用ワークスペースの構築 皆さんも、AIパートナーとしてClaudeを活用する際は、Notionの構造も合わせて最適化していくことをおすすめします。 まとめ 今回の記事では、Claude ProとNotion MCPを接続するための複数の方法を紹介しました。コネクタ版は簡単に始められる一方、Integration版はより細かい制御が可能です。どの方法を選ぶにしても、AIとNotionの連携によって情報管理と創造性が大きく向上するでしょう。ぜひ皆さんも試してみてください! ご覧いただきありがとうございます! この投稿はお役に立ちましたか? 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude×Notion MCP実装術|コネクタ版とIntegration版の選び方解説 first appeared on SIOS Tech. Lab .
はじめに Git & GitLab入門ブログ Gitマスターへの道の第2回です。前回の「 Gitの基本とGitLab / GitHubについて 」では、Gitの基本を解説しました。 今回は、ローカルPCにGit、VSCodeを導入し、最初のコミットを行うまでの手順を解説します。Windows環境をメインに説明しますが、他のOSをご利用の方にも役立つ情報を含んでいます。 初期環境構築 Gitを使い始めるためには、まずお使いのPCにGitをインストールし、基本的な設定を行う必要があります。 今回のGit操作入門では、VSCodeを使用してGitの操作やコードの編集を説明します。 Gitのインストール Gitの公式サイト( https://git-scm.com/download/win )にアクセスし、最新のインストーラーをダウンロードします。 ダウンロードしたインストーラーを実行します。インストール中の設定は、特にこだわりがなければすべてデフォルトのままで問題ありません。「Next」をクリックしていき、インストールを完了させてください。 Windows + R から「ファイル名を指定して実行」を開き、「cmd」と入力してEnterキーを押し、コマンドプロンプトを開きます。以下のコマンドを実行してバージョンが確認されれば成功です。 $ git --version VS Codeのインストール VS Codeの公式サイト( https://code.visualstudio.com/download )にアクセスし、Windows版のインストーラーをダウンロードします。 ダウンロードしたインストーラーを実行します。「同意する」を選択し、「次へ」をクリックしてインストールを進めます。 この際、「Codeで開く」アクションをエクスプローラーのコンテキストメニューに追加するオプションにチェックを入れておくと便利です。 その他のOSについて(Mac/Linux) Mac:Homebrew ( https://brew.sh/index_ja ) を利用するのが最も簡単です。ターミナルで以下のコマンドを実行してください。 $ brew install git VS Codeも公式サイトからダウンロード・インストールできます。 Linux:各ディストリビューションのパッケージマネージャーを利用します。例えばUbuntuであれば、ターミナルで以下のコマンドを実行します。 $ sudo apt update && sudo apt install git VS Codeも公式サイトから.debや.rpmパッケージをダウンロードしてインストールできます。 ユーザー名とメールアドレスの設定 Gitをインストールしたら、コミットの際に記録されるユーザー名とメールアドレスを設定します。これは、誰がどの変更を行ったかを識別するために重要です。 コマンドプロンプトを開き、以下のコマンドを実行してください。 $ git config --global user.name "名前" $ git config --global user.email "メールアドレス" “名前” の部分には、表示したいユーザー名を記載してください。これは、GitHubなどでもコミット履歴として確認されます。 “メールアドレス” の部分には、普段お使いのメールアドレスを記載してください。 この設定は–globalオプションを付けているため、一度設定すれば、そのPC上のすべてのGitリポジトリに適用されます。 VSCodeにおける操作 (windows) VS Codeの左側にあるソース管理アイコンから後述するGitの操作が可能です。 この機能により、本来 コマンドプロンプトで実行するGit操作がGUI上でも実行可能となります。 ローカルリポジトリの作成 Gitでバージョン管理を始めるには、まず、リポジトリを作成する必要があります。前回説明しましたが、Gitリポジトリにはローカルリポジトリとリモートリポジトリの2種類あります。 今回は、手元のPCに作成する「ローカルリポジトリ」を作成します。VSCodeなどの開発時に利用するエディタの拡張機能を用いてGitを管理する事で、利便性や効率性を持たせてGitを扱うことが出来ます。 VS Codeを開き、「ファイル」>「フォルダーを開く」を選択します。 Gitで管理したいプロジェクトのフォルダー(例:git-tutorial)を新しく作成し、そのフォルダーを選択して開きます。 VS Codeの左側にあるソース管理アイコンをクリックします。 「リポジトリを初期化」ボタンをクリックします。 コマンドで実行する場合は、VSCodeからCtrl + @ でターミナルを起動し、以下のコマンドを実行します。 $ git init これで、指定したフォルダーがGitによって管理されるようになり、ローカルリポジトリが作成されました。フォルダー内に.gitという隠しフォルダーが作成されていれば成功です。 最初のコミット リポジトリを作成したら、最初のファイルを作成し、それをGitに記録(コミット)してみます。 コミットの基本的な流れは、以下の3つのステップから構成されます。 変更 この時点ではまだ、その変更がGitのバージョン管理の対象として確定されたわけではありません。例えるなら、ノートに下書きを書いた状態です。 ステージング 変更を加えたファイルをGitのバージョン管理に含めるためには、「ステージングエリア」と呼ばれる一時的な領域に、その変更を「ステージ(追加)」する必要があります。ステージングのステップが必要な理由のひとつとしては、一度に複数のファイルを変更した場合でも、その中の特定の変更だけをコミットしたい場合に対応するためです。 コミット ステージングエリアに準備が整った変更を、最終的にGitのバージョン履歴として確定させる操作です。いくつかの呼称がありますが、コミットはコミットIDという一意のハッシュ値で識別されます。 最初のファイルを作成していきます。VS Codeの左側のエクスプローラービューで先ほど作成したフォルダー内に新しいファイルを作成します。例えば、index.phpというファイルを作成し、以下の内容を記述します。 Hello world! ファイルを保存すると、VS Codeのソース管理ビューにindex.phpが「変更」として表示されます。これは、Gitがファイルに変更があったことを検知している状態です。 ndex.phpの行にマウスカーソルを合わせると表示される「ステージング」(プラスアイコン)をクリックします。これにより、index.phpがコミットの対象として選択(ステージ)されます。 ターミナルで実行する場合は、以下のコマンドを実行します。 $ git add index.php 上部のテキストボックスにコミットメッセージを入力します。コミットメッセージは、そのコミットでどのような変更を行ったかを簡潔に説明するものです。今回は「Initial commit」と入力しましょう。 コミットメッセージを入力したら、上部のチェックマークアイコン(コミットボタン)をクリックします。 ターミナルで実行する場合は、以下のコマンドを実行します。 $ git commit -m “Initial commit” これで、最初のコミットが完了しました。Gitはindex.phpの現在の状態を履歴として保存しました。 改めてGit操作の第1歩としてはまず、ローカルリポジトリ上での変更→ステージング→コミットの流れについて覚えていくのが重要です。 まとめ 今回はGitの環境構築と最初のコミットなどを解説しました。これでバージョン管理に足を一歩踏み入れました。次回はチーム開発に向けて解像度を上げるために、他のGitの機能やコミットの戻し方等を解説します。 ご覧いただきありがとうございます! この投稿はお役に立ちましたか? 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Git & GitLab 入門 (2) ~Git マスターへの道~「Git操作入門」 first appeared on SIOS Tech. Lab .
Material Designをはじめとして、グラフィカルユーザーインターフェース(GUI)のデザインシステムは数多く公開されています。 各デザインシステムに含まれるUIコンポーネントは、各ブランドやサービスに最適化された独自の内容ですが、基本的な部分は共通しています。 たとえば「Button」コンポーネントは、どのデザインシステムでも、同じ役割かつ同じ名前で定義されています。 一方、役割は概ね同じでも、名称が異なるケースもあります。 この記事では、そのようなケースの具体例を挙げながら、UIコンポーネントの名称を整理します。 各デザインシステムのコンポーネントのカタログ化の粒度がさまざまで、グループ化の判定は筆者独自のものですが、複数のデザインシステムを参照する際の参考になれば幸いです。 今回対象としたデザインシステムやUI Kit Apple Human Interface Guidelines Bootstrap Atlassian Design System Material Design(Google) Carbon Design System(IBM) U.S. Web Design System(USWDS) GOV.UK Design System SmartHR Design System デジタル庁デザインシステム Fluent 2(Microsoft) Shadcn/ui (コンポーネント名は、オリジナルが複数形の場合も単数形に変更して統一しています。例:Chips → Chip) テキスト入力:「Text field」「Text input」など UIコンポーネント名 デザインシステム Text field Apple Atlassian Material Design(Google) Text input Carbon(IBM) USWDS GOV.UK Input SmartHR Fluent 2(Microsoft) Shadcn/ui Input text デジタル庁 テキストを入力する基本的なコンポーネントです。 「Text input」や「Input」は、HTMLの<input type=”text”>と一致する名称です。(inputタグのデフォルトタイプはtext) なお、Material Design、USWDS、Appleは、1行のみの入力と複数行の入力を1つのUIコンポーネントにまとめています。 それ以外のデザインシステムでは、1行入力を「Text input」、複数行入力を「Textarea」のように、コンポーネントを分けているケースが多いです。 これもHTMLの<textarea>タグに合わせた名称です。 確認するもの:「Dialog」「Modal Dialog」など UIコンポーネント名 デザインシステム Dialog Material Design(Google) SmartHR Fluent 2(Microsoft) Shadcn/ui Modal Bootstrap Carbon(IBM) USWDS Modal dialog Atlassian デジタル庁 Alert Apple Alart Dialog Shadcn/ui 「ダイアログ」は直訳すると「対話」です。 「モーダル」は「モードの」という意味で、ひとつのモードに入っていて他の操作をさせないことを示します。対義語は「モードレス」です。 上記のコンポーネントの多くがモーダルな動作をしますが、たとえばSmartHRには「ModelessDialog」も存在します。 また、Material Designや、Bootstrapでは、フルスクリーン表示もサポートされています。 Shadcn/uiでは「Dialog」と「Alart Dialog」が別に定義されています。 左右でオンとオフを選ぶ:「Switch」「Toggle」 UIコンポーネント名 デザインシステム Switch Apple Bootstrap Material Design(Google) SmartHR Fluent 2(Microsoft) Shadcn/ui Toggle Atlassian Carbon(IBM) Appleでは「Switch」「Checkbox」「Radio Button」など、2つの状態を選択させることをまとめて「Toggle」として案内しています。 また、Shadcn/uiでは、「Switch」と「Toggle」が別のコンポーネントとして定義されています。Toggleはシンプルなボタン表現です。 なお、「Switch」と「Checkbox」は、どちらもオンオフの二択入力ですが、「Checkbox」が入力後に登録ボタンを押して有効になるのに対し、「Switch」は入力と同時に有効とするのが、一般的な使い分けです。 小さい情報:「Chip」「Tag」 UIコンポーネント名 デザインシステム Chip Material Design(Google) SmartHR Tag Atlassian Carbon(IBM) USWDS GOV.UK Fluent 2(Microsoft) 「ソーシャルタグ」「ハッシュタグ」「タグ付け」など、テキスト情報(ラベル)に着目した名前が「Tag」です。 これに対して、「Chip」はテキストなどが乗っているオブジェクトに焦点を当てたネーミングだと考えられます。 ひょっこり現れる:「Snackbar」「Toast」など UIコンポーネント名 デザインシステム Snackbar Material Design(Google) Toast Bootstrap Carbon(IBM) Fluent 2(Microsoft) Sonner Shadcn/ui Flag Atlassian 画面の外側からスライドして現れ、状態の変化や警告などをオーバーレイで表示するコンポーネントです。 Shadcn/uiでは以前からあった「Toast」コンポーネントを非推奨にして、代わりに「Sonner」が追加されました。 「Sonner」は「Toast」を基本としたコンポーネントのようです。 以下は、各名称について筆者の解釈です。 「Snackbar」は少ない情報を提供することを、軽食店に例えた。 「Toast」はトースターからパンが飛び上がる様子から。 「Flag」は注意を引く際の旗を上げる様子から。 「Sonner」はフランス語の「(警報などが)鳴り響く、知らせる」の意味の単語から。 ご覧いただきありがとうございます! この投稿はお役に立ちましたか? 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post そのUIどう呼ぶ?チームの認識を揃えるためのコンポーネント名称整理 first appeared on SIOS Tech. Lab .
今号では、systemd.timer について、その仕組みや設定方法について説明します! 前回と前々回の記事では cron についてご紹介したので、cron の代替として位置づけられている systemd.timer についても知っておくことで、よりタスク管理を理解できるかと思います。 systemd.timer とは systemd.timer とは、以前ご紹介した cron のように定期的にタスクを実行してくれる機能の名称です。RHEL9 以降、タスク管理の仕組みとして cron ではなく systemd.timer が標準として搭載されています。 ※ cron を使用することもできますが、デフォルトで配置されていたいくつかのジョブは systemd.timer へ移行しています。 cron は crond というデーモンとして動作するのに対し、systemd.timer は systemd が提供する機能のひとつ として動作します。 具体的な機能、設定方法についてはこの後ご説明しますが、systemd.timer は cron と比較して、書式がよりシンプルに変更されていたり、時間指定がより柔軟に設定できるようになっています。 Linux におけるタスク管理とは何か?については、cron の記事で詳しく説明していますので、ぜひご参照ください! ・ 知っておくとちょっと便利!cron によるタスク管理1 ・ 知っておくとちょっと便利!cron によるタスク管理2 systemd.timer の設定ファイル、ディレクトリ構成 systemd.timer は、基本的に下記 2つのファイルで構成されます。 (※今回は RHEL9 の環境を前提に説明します)  ・ .timer ファイル :スケジュールを定義します。  ・ .service ファイル :実行するコマンドやスクリプトを定義します。 .timer ファイルで指定されたスケジュール (日時や間隔) に基づいて、対応する .service ファイルに記載された内容を処理します。 (例えば、A.timer には A.service というファイルが対応します) これらのファイルは、デフォルトは /usr/lib/systemd/system もしくは /etc/systemd/system 配下に配置されています。 なお、ユーザが独自の .timer や .service を定義したい場合は、通常 /etc/systemd/system 配下に各ファイルを配置します。 ちなみに、ファイルの内容は /usr/lib/systemd/system よりも /etc/systemd/system の方が優先されるため、既存の .timer や .service の内容に新しい処理を上書きしたい場合も、 /usr/lib/systemd/system 配下のファイルを直接編集するのではなく /etc/systemd/system 配下にファイルを配置することを推奨しています。 systemd.timer の設定方法 まずは既存のファイルの内容から、どのような設定ができるのかを見ていきたいと思います。 例として、logrotate.timer の内容を見てみます。 logrotate.timer の内容 [Unit] Description=Daily rotation of log files Documentation=man:logrotate(8) man:logrotate.conf(5) [Timer] OnCalendar=daily AccuracySec=1h Persistent=true [Install] WantedBy=timers.target [Unit] セクション timer ユニットの一般的な情報とドキュメントを定義します。 Description このユニットの概要です。 Documentation このユニットに関連するドキュメント情報です。 [Timer] セクション タスクがいつ、どのように動作するか定義します。 OnCalendar=daily タスク (この場合ですと、logrotate.service) が実行される頻度を指定します。 daily は毎日実行されることを意味します。 他には hourly(毎時)、weekly(毎週)、特定の日付や時刻 なども指定できます。 AccuracySec=1h 精度を指定します。1h は 1時間を意味します。 これは、タスクが OnCalendar で指定された時刻から最大 1時間の遅延を許容することを示します。 これにより、すべてのタスクが同時に起動してシステムに負荷をかけるのを避けることができます。 他には s(秒)、m(分)、d(日) なども指定できます。 Persistent=true この設定が true である場合、システムがシャットダウンしている間に実行されるはずだったタスクが、システム起動後直ちに実行されるようになります。 反対に、この設定が false である場合 (もしくは設定されていない場合、デフォルトでは false の動作となる)、スケジュールした時間になってもタスクが実行されなかった場合、そのタイミングでの実行は一度スキップされ、次回の実行タイミングまで待ちます。 [Install] セクション ユニットが有効化された時の動作を指定します。 WantedBy=timers.target systemctl enable (システム起動時に、当該のサービスを自動的に有効化する) である場合、どのタイミングで有効化されるかを決めます。 この設定が timers.target である場合、タイマー (定期実行されるタスク) の動作準備が完了したタイミングで、当該のサービスが起動されます。 .timer ファイルを使用している場合は、この設定を使用することが多いです。 他には multi-user.target (サービスの動作準備が完了したタイミング)、 graphical.target (GUI 環境が使用可能になったタイミング)、 なども指定できます。 systemd.timer に設定可能な項目は、他にもたくさんあります。 より詳しく知りたい方は、 man systemd.timer コマンドでマニュアルを確認してみてください。 次号について 次号では、 systemd.timer によるタスク管理の tips についてご紹介します! ご覧いただきありがとうございます! この投稿はお役に立ちましたか? 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 知っておくとちょっと便利!systemd.timer によるタスク管理1 first appeared on SIOS Tech. Lab .
こんにちは! 今月も「OSSのサポートエンジニアが気になった!OSSの最新ニュース」をお届けします。 Linux 環境でよく使用される sudo において、影響度の高い脆弱性 (CVE-2025-32463) が報告されました。 Linux sudo chrootの脆弱性(CVE-2025-32463)により、非特権ユーザーがroot権限を取得可能に https://rocket-boys.co.jp/security-measures-lab/linux-sudo-chroot-cve-2025-32463-root-escalation/ 2025/7/3、Cloud Native Computing Foundation (CNCF) の 2024年アニュアルレポートの日本語版が公開されました。 CNCF アニュアル レポート 2024 日本語版を公開 https://prtimes.jp/main/html/rd/p/000000374.000042042.html 2025/7/16、Google が CVE-2025-6558 の脆弱性に対する Chrome の緊急アップデートをリリースしました。 Urgent: Google Releases Critical Chrome Update for CVE-2025-6558 Exploit Active in the Wild https://thehackernews.com/2025/07/urgent-google-releases-critical-chrome.html ご覧いただきありがとうございます! この投稿はお役に立ちましたか? 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【2025年7月】OSSサポートエンジニアが気になった!OSS最新ニュース first appeared on SIOS Tech. Lab .
挨拶 ども!お久しぶりです。Claudeを活用した開発手法の模索に真剣に取り組んでいる龍ちゃんです。 合間でStreamlitアプリの開発もちょこちょこやっているんですが、前回は「 DevContainerでStreamlit開発を始める方法:Docker+VSCode 」でStreamlitの開発コンテナ環境を構築しました。 開発環境は整ったものの、「いざ本番環境にデプロイしようとしたら、設定が開発環境のままで困った…」という経験、皆さんもありませんか?実際に私も最初の頃、開発用の設定のままAzureにデプロイして、エラー情報が丸見えになってしまったことがあります。 今回はそんな課題を解決するため、 本番環境用Dockerfileの構築手法 を共有していきたいと思います! 今回の内容 : 「Streamlit 本番環境用Dockerfileの作成」 セキュリティを考慮したコンテナ設計 開発環境と本番環境の適切な設定分離 プロダクション向けStreamlit最適化 事前準備 事前準備として、 前回のVSCode環境で、コンテナを用いてStreamlit環境を構築した記事 の内容をベースに進めていきます。 まだ環境が整っていない方は、その記事を参考に環境を構築するか、 サンプルリポジトリ を参照してください。 前提条件 : Docker Desktop がインストール済み 基本的なStreamlitアプリが作成済み VSCodeでの開発経験(推奨) 今回の内容はStreamlitのDockerビルドに関するものですが、環境が完全に一致していなくても動作します。使える部分だけを取り入れていただければ問題ありません。 今回の目標 今回の目標は、 本番環境用のDockerfileを作成し、実際にローカルでビルド・動作確認すること です。 また、Streamlit用のプロダクション環境向け設定ファイル(config.prod.toml)の作成も目指しています。 具体的な手順 : 本番環境用Dockerfileの作成 Streamlit設定ファイル(config.prod.toml)の最適化 Dockerコマンドを用いた動作確認 最終的な成果物 : セキュリティを考慮した本番環境用Dockerfile プロダクション最適化されたStreamlit設定 即座にデプロイ可能なDockerイメージ 今回作成するディレクトリ構造は以下のようになります: . ├── .devcontainer │ ├── Dockerfile │ ├── compose.yml │ └── devcontainer.json ├── .gitignore ├── .streamlit │ └── config.prod.toml # 本番環境用Streamlit設定ファイル ├── Dockerfile # 本番環境用Dockerfile ├── README.md ├── requirements.txt ├── setup.cfg └── src ├── chat.py ├── demo.py └── main.py 開発環境と本番環境の設定戦略 ここで重要なのが、 開発環境と本番環境の設定を明確に分離する ことです。実際のプロジェクトでどちらを選ぶべきか、迷うところですよね。 開発環境の特徴 開発環境では、特別な設定を行っていませんでした。これはStreamlitのデフォルト設定に開発者向けの便利機能がすでに組み込まれているからです: エラーメッセージの詳細表示 : デバッグに便利 ファイル変更時の自動リロード : ホットリロード機能 開発者ツールの表示 : パフォーマンス情報など 詳細なデバッグ情報 : トラブルシューティングに有用 本番環境での課題 一方、本番環境ではこれらの機能は不要どころか、 ユーザー体験を損なう要因 になります: エラーの詳細情報がエンドユーザーに表示される(セキュリティリスク) 不要な開発者ツールが表示されて混乱を招く そもそもソースコードが変更されることがないのでリロード機能は不要 リソース使用量が最適化されていない 設定分離のメリット そこで、本番環境専用の設定ファイル(config.prod.toml)を作成することで: セキュリティ向上 : 不要な情報の非表示化 パフォーマンス最適化 : 開発機能の無効化 ユーザー体験向上 : クリーンなインターフェース 運用効率化 : 環境に応じた適切な設定 また、VSCode開発時に必要な情報(.vscodeディレクトリなど)や開発時にのみ必要な情報を本番環境のビルドに含めないことで、 より軽量なDockerイメージ を実現できます。 開発環境では、DevContainerで開発するために専用イメージを使用していましたが、これには多くの設定が含まれた重いイメージになっています。本番環境ではこれらを削ぎ落として、極力小さなベースイメージを使用したいという意図があります。 環境分離のメリットとしては、 イメージの軽量化 や 不要情報の削除によるセキュリティリスクの回避 が挙げられます。 本番環境用Dockerfileの詳細解説 それでは、本番環境用Dockerfileについて詳しく見ていきます。 ベースイメージの選択に関しては、こちらの「 Dockerイメージの選び方ガイド 」が参考になります。 Dockerfileのベースとしては、 公式リファレンスの「Deploy Streamlit using Docker」 を参照しています。 # 本番環境用 - Python 3.11 slim イメージ FROM python:3.11-slim # 非rootユーザーでの実行(セキュリティ対策) RUN groupadd -r appuser && useradd -r -g appuser appuser # 作業ディレクトリの設定 WORKDIR /app # システムの更新と必要最小限のパッケージをインストール RUN apt-get update \ && apt-get install -y --no-install-recommends \ curl \ ca-certificates \ && apt-get clean \ && rm -rf /var/lib/apt/lists/* # Pythonの設定(パフォーマンス最適化) ENV PYTHONDONTWRITEBYTECODE=1 \ PYTHONUNBUFFERED=1 \ PIP_NO_CACHE_DIR=1 \ PIP_DISABLE_PIP_VERSION_CHECK=1 # ヘルスチェック HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \ CMD curl -f http://localhost:8501/_stcore/health || exit 1 # 依存関係ファイルをコピー COPY requirements.txt . # Pythonパッケージのインストール RUN pip install --no-cache-dir -r requirements.txt # アプリケーションコードをコピー COPY ./src . # Streamlit設定ファイルを作成 RUN mkdir -p .streamlit COPY .streamlit/config.prod.toml .streamlit/config.toml # ファイルの所有権を変更(セキュリティ対策) RUN chown -R appuser:appuser /app # 非rootユーザーに切り替え USER appuser # ポート公開 EXPOSE 8501 # Streamlitアプリの起動 CMD ["streamlit", "run", "main.py"] ベースイメージの選択理由 こちらが本番環境のDockerfileになります。ベースイメージとしては、 Python 3.11のslimイメージ を使用し、開発環境と同じバージョンに揃えています。 slimイメージを選択した理由: 必要最小限のパッケージのみ含有(セキュリティリスク軽減) イメージサイズが小さい(デプロイ時間短縮) 本番環境に不要な開発ツールが含まれていない セキュリティ対策のポイント セキュリティのために 非rootユーザーでの実行 を行うためにユーザーを作成し、システムの更新と必要最小限のパッケージのインストールも実施しています。 パフォーマンス最適化の工夫 Pythonアプリケーションを動かすための手順としては、まず依存ファイルをコピーして必要なパッケージをインストールし、その後、srcディレクトリ内のアプリケーションコードとStreamlitの設定ファイルをコピーしています。 設定ファイルの適切な管理 特に重要な点は Streamlitの設定ファイル(config.toml)の作成部分 です。.streamlitディレクトリを作成し、ホスト側にある.streamlitディレクトリ内の config.prod.toml ファイルを、コンテナ内では単に config.toml としてコピーしています。 これにより、設定項目が本番環境用のconfigとして正しく認識され、プロダクション用の設定を適切に管理できます。また、config.prod.tomlというファイル名にすることで、開発環境では読み込まれないという利点もあります。 公開ポートとしては8501を指定し、最終的にStreamlitを起動するコマンドを実行しています。 Stremlit HealthCheckについて 公式のこちらのページ でDockerのコンテナが起動しているかをHealth Checkを行っています。これはStreamlitを確実に動作させるために必要なので追加しておきます。 ヘルスチェックにより、コンテナオーケストレーション(Kubernetes、Docker Swarm等)が自動的に異常なコンテナを検知・再起動できるようになります 本番環境用Streamlit設定(config.prod.toml) このファイルは 本番環境用のStreamlit設定ファイル です。詳細な内容については、 Streamlit公式のドキュメント を参照してください。 ファイル内には一通り必要な設定項目にコメントを付けていますので、それぞれの設定が必要かどうか判断していただければと思います。 実装としては以下のようになります: # Streamlit 本番環境用設定ファイル # 各設定項目の詳細説明付き [server] # ブラウザを自動で開かない(サーバー環境での実行に適している) # デフォルト: false headless = true # Streamlitアプリが待ち受けるポート番号 # デフォルト: 8501 port = 8501 # サーバーがリッスンするIPアドレス # "0.0.0.0" で全てのネットワークインターフェースからの接続を許可 # デフォルト: (未設定) address = "0.0.0.0" # 静的ファイル配信機能を無効化(セキュリティ向上) # staticディレクトリからのファイル配信を禁止 # デフォルト: false enableStaticServing = false # ファイル変更時の自動再実行を無効化(本番環境では不要) # 開発環境でのみ有効にすべき機能 # デフォルト: false runOnSave = false [browser] # Streamlitへの使用統計送信を無効化(プライバシー保護) # 本番環境では通常無効化する # デフォルト: true gatherUsageStats = false # ブラウザが接続すべきサーバーアドレス # コンテナ環境では "0.0.0.0" を指定 # デフォルト: "localhost" serverAddress = "0.0.0.0" # ブラウザが接続すべきポート番号 # server.portと同じ値を設定 # デフォルト: server.portの値 serverPort = 8501 [global] # 開発モードを無効化(本番環境用の設定) # 開発者向け機能や詳細なエラー表示を制限 # デフォルト: false developmentMode = false # 直接実行時の警告表示を無効化 # "python script.py" での実行時の警告を非表示 # デフォルト: true showWarningOnDirectExecution = false [client] # エラー詳細の表示レベル設定 # "full": 完全なエラー情報を表示(本番環境でも詳細確認のため有効) # 他の選択肢: "stacktrace", "type", "none" # デフォルト: "full" showErrorDetails = "full" # ツールバーの表示モード設定 # "viewer": 開発者オプションを非表示(本番環境に適している) # 他の選択肢: "auto", "developer", "minimal" # デフォルト: "auto" toolbarMode = "viewer" # マルチページアプリでのサイドバーナビゲーション表示 # pages/ディレクトリベースのナビゲーションを有効化 # デフォルト: true showSidebarNavigation = true [ui] # Streamlitのトップバーを非表示 # より洗練されたUIを実現(ブランディング向上) # カスタム設定項目 hideTopBar = true [theme] # ダークテーマを適用 # "light" または "dark" から選択可能 # ユーザー体験向上のためのテーマ設定 base = "dark" セキュリティの機能(CORSやXSRF)などの保護機能を無効化にすることもできますが、ここはデプロイ先の構成によって検討するべき内容です。十分に注意して設定項目を決定してください。 Streamlit公式フォーラムでも言及されています 。 動作確認 それでは、実際に作成したDockerfileとconfig.prod.tomlを使って動作確認を行ってみます。 Dockerイメージのビルド まずはDockerイメージをビルドしてみましょう: # Dockerイメージのビルド docker build -t python-app:test . コンテナの起動と確認 次に、ビルドしたイメージを使ってコンテナを起動します: # コンテナの実行 # DevContainerで8501を使用している可能性を考慮して8502に接続 docker run -d -p 8502:8501 --name python-app-test python-app:test # ログ確認 docker logs python-app-test # ブラウザでアクセス # http://localhost:8502 クリーンアップ 動作確認が完了したら、コンテナを停止・削除します: # コンテナの停止と削除 docker stop python-app-test docker rm python-app-test # 不要なイメージの削除(必要に応じて) docker rmi python-app:test よくあるエラーと対処法 ポートが既に使用されている場合 # エラー: port is already allocated # 対処法: 別のポートを使用 docker run -d -p 8503:8501 --name python-app-test python-app:test 設定ファイルが見つからない場合 # .streamlit/config.prod.toml の存在確認 ls -la .streamlit/ # ファイルパスの確認 COPY .streamlit/config.prod.toml .streamlit/config.toml 権限エラーが発生する場合 # ファイル所有権の確認 docker exec -it python-app-test ls -la /app まとめ 今回は Streamlit本番環境用Dockerfileの構築 について詳しく見てきました。 開発環境と本番環境の設定を適切に分離することで、セキュリティとパフォーマンスの両方を向上させることができました。特に config.prod.toml による設定最適化と、 非rootユーザー でのコンテナ実行は、実際のプロジェクトでも重要なポイントになります。 今回作成したDockerfileは、Azure Container InstancesやAWS Fargate等のクラウドサービスにそのままデプロイできる構成になっています。 次回は、 GitHub Actions + Bicep を使った 完全自動化デプロイパイプライン の構築に挑戦します!今回のDockerfileがそのまま活用できるので、ぜひお楽しみに! それでは、次回の記事でまたお会いしましょう! ご覧いただきありがとうございます! この投稿はお役に立ちましたか? 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Streamlit本番環境Docker構築ガイド|セキュリティ設定分離完全対応 first appeared on SIOS Tech. Lab .
PS SLの佐々木です。 今回はClaude Codeを使っていてToDoリストがどのように管理されているのかやタスク完遂まで具体的にどのような作業が行われているのかを知りたく~/.claudeディレクトリを観察してみました。なので備忘録的な内容になっています。 ~/.claude ディレクトリの構造 Claude Codeを使い始めると、ユーザーのホームディレクトリに ~/.claude という隠しディレクトリが自動的に作成されます。このディレクトリには、Claude Codeの動作を支える重要なファイルが格納されています。本記事では、実際にNext.jsプロジェクトをセットアップする際の挙動を通して、これらのファイルの詳細な役割と仕組みを解説します。 ~/.claude/ ├── .credentials.json ├── projects/ ├── shell-snapshots/ ├── statsig/ └── todos/ 各ファイル・ディレクトリの役割 .credentials.json Claude CodeがAnthropic APIに接続するための認証情報を保存するファイルです。APIキーなどの重要な認証データが含まれています。 projects/ Claude Codeのセッション履歴を記録するディレクトリです。各プロジェクトでの作業内容が詳細なJSONログとして保存されます。 shell-snapshots/ コマンドライン作業の履歴やセッションのスナップショットを保存するディレクトリです。(多分) statsig/ 使用統計やアナリティクス関連のデータを保存するディレクトリです。(多分) todos/ Claude Codeの特徴的な機能であるTODO管理システムのデータが保存されるディレクトリです。 TODOシステムの詳細な動作 初期状態 Claude Codeを実行すると、 todos ディレクトリ内に空のJSONファイルが作成されます: $ ls ~/.claude/todos/ 567fef6f-1c7f-4b9e-883c-1f5e7478d125-agent-567fef6f-1c7f-4b9e-883c-1f5e7478d125.json $ cat ~/.claude/todos/567fef6f-1c7f-4b9e-883c-1f5e7478d125-agent-567fef6f-1c7f-4b9e-883c-1f5e7478d125.json [] ファイル名はセッションIDベースで生成され、初期状態では空の配列となっています。 TODOタスクの自動生成 ユーザーが複雑なタスクを依頼すると、Claude Codeは自動的にタスクを分解してTODOリストを作成します。 入力例: Next.jsのプロジェクトをセットアップしてください。 Next.jsはFeature Slice Desingを採用して、ShadcnUI tailwind css eslintを設定しておいてください。 Claude Codeの応答: ● Next.jsプロジェクトをセットアップします。Feature Slice Design、ShadcnUI、TailwindCSS、ESLintを設定します。 ● Update Todos ⎿ ☐ Next.jsプロジェクトを初期化 ☐ TailwindCSSを設定 ☐ ShadcnUIを設定 ☐ ESLintを設定 ☐ Feature Slice Designのディレクトリ構造を作成 この時点で、TODOファイルには以下のデータが保存されます: [ { "content": "Next.jsプロジェクトを初期化", "status": "pending", "priority": "high", "id": "1" }, { "content": "TailwindCSSを設定", "status": "pending", "priority": "high", "id": "2" }, { "content": "ShadcnUIを設定", "status": "pending", "priority": "high", "id": "3" }, { "content": "ESLintを設定", "status": "pending", "priority": "high", "id": "4" }, { "content": "Feature Slice Designのディレクトリ構造を作成", "status": "pending", "priority": "medium", "id": "5" } ] タスクステータスの動的更新 Claude Codeは作業の進行に合わせて、TODOのステータスを自動的に更新します: pending : 未着手 in_progress : 作業中 completed : 完了 作業完了後のTODOファイル: [ { "content": "Next.jsプロジェクトを初期化", "status": "completed", "priority": "high", "id": "1" }, { "content": "TailwindCSSを設定", "status": "completed", "priority": "high", "id": "2" }, { "content": "ShadcnUIを設定", "status": "completed", "priority": "high", "id": "3" }, { "content": "ESLintを設定", "status": "completed", "priority": "high", "id": "4" }, { "content": "Feature Slice Designのディレクトリ構造を作成", "status": "completed", "priority": "medium", "id": "5" } ] セッション履歴の詳細記録 projects/ ディレクトリには、Claude Codeでの全ての対話が詳細に記録されます。ファイル形式はNDJSON(改行区切りJSON)で、以下の情報が含まれます: ログエントリの構造 { "parentUuid": "親メッセージのID", "isSidechain": false, "userType": "external", "cwd": "/home/ka-sasaki/claude-product/my-next-app", "sessionId": "567fef6f-1c7f-4b9e-883c-1f5e7478d125", "version": "1.0.55", "gitBranch": "", "type": "assistant", "message": { "role": "assistant", "content": [ { "type": "tool_use", "name": "Bash", "input": { "command": "npx create-next-app@latest my-next-app", "description": "Next.jsプロジェクトを初期化" } } ] }, "uuid": "メッセージのユニークID", "timestamp": "2025-07-18T08:02:37.376Z" } 対話パターンの分析 Claude Codeの対話は必ず以下のパターンで進行します: Assistant : ツール実行の指示 User : ツール実行結果の報告 Assistant : 次のアクションの決定 User : 結果の報告… この交互パターンにより、Claude Codeは複雑なタスクを段階的かつ確実に実行できます。 実際の作業フローの例 ShadcnUI初期化の4ステップ: Bashコマンド実行 { "type": "assistant", "content": [{ "type": "tool_use", "name": "Bash", "input": { "command": "echo \\"\\" | npx shadcn@latest init", "description": "デフォルト設定でShadcnUIを初期化" } }] } コマンド実行結果の受信 { "type": "user", "content": [{ "tool_use_id": "...", "type": "tool_result", "content": "Success! Project initialization completed..." }] } TODOリストの更新指示 { "type": "assistant", "content": [{ "type": "tool_use", "name": "TodoWrite", "input": { "todos": [ {"id": "3", "content": "ShadcnUIを設定", "status": "completed", ...} ] } }] } TODO更新結果の確認 { "type": "user", "content": [{ "tool_use_id": "...", "type": "tool_result", "content": "Todos have been modified successfully..." }], "toolUseResult": { "oldTodos": [...], "newTodos": [...] } } まとめ Claude Codeの ~/.claude ディレクトリは、単なる設定ファイルの保存場所ではなく、高度なプロジェクト管理システムの中核を担っています。TODOシステムによる自動的なタスク分解と進捗管理、詳細なセッション履歴の記録により、開発者は複雑なタスクを効率的に進められます。 構造が理解できると作業内容を修正したり、意図しない挙動をしたときにデバックができたりとメリットも大きいですね。 ではまた おまけ {"parentUuid":null,"isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","type":"user","message":{"role":"user","content":"Next.jsのプロジェクトをセットアップしてください。\\nNext.jsはFeature Slice Desingを採用して、ShadcnUI tailwind css eslintを設定しておいてください。"},"uuid":"8dc008ac-ccfb-460c-8fdf-450d23b4b966","timestamp":"2025-07-18T08:01:09.513Z"} {"parentUuid":"8dc008ac-ccfb-460c-8fdf-450d23b4b966","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","type":"assistant","uuid":"86eaec54-39b4-48b0-b94c-8bbe73a7d988","timestamp":"2025-07-18T08:01:09.601Z","message":{"id":"4bc10eb6-bdfe-4244-8b24-f13bacf54e78","model":"<synthetic>","role":"assistant","stop_reason":"stop_sequence","stop_sequence":"","type":"message","usage":{"input_tokens":0,"output_tokens":0,"cache_creation_input_tokens":0,"cache_read_input_tokens":0,"server_tool_use":{"web_search_requests":0},"service_tier":null},"content":[{"type":"text","text":"Invalid API key · Please run /login"}]},"isApiErrorMessage":true} {"parentUuid":"86eaec54-39b4-48b0-b94c-8bbe73a7d988","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","type":"user","message":{"role":"user","content":"Caveat: The messages below were generated by the user while running local commands. DO NOT respond to these messages or otherwise consider them in your response unless the user explicitly asks you to."},"isMeta":true,"uuid":"5ff28893-00c1-4c17-9d1c-2fa1ffaf14bf","timestamp":"2025-07-18T07:49:26.692Z"} {"parentUuid":"5ff28893-00c1-4c17-9d1c-2fa1ffaf14bf","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","type":"user","message":{"role":"user","content":"<command-name>/login</command-name>\\n <command-message>login</command-message>\\n <command-args></command-args>"},"uuid":"d02d0a28-b304-4308-8403-a6524a0fc633","timestamp":"2025-07-18T08:02:05.549Z"} {"parentUuid":"d02d0a28-b304-4308-8403-a6524a0fc633","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","type":"user","message":{"role":"user","content":"<local-command-stdout>Login successful</local-command-stdout>"},"uuid":"64729a1d-aa54-41cd-814d-423eb41590bf","timestamp":"2025-07-18T08:02:05.549Z"} {"parentUuid":"64729a1d-aa54-41cd-814d-423eb41590bf","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","type":"user","message":{"role":"user","content":"Next.jsのプロジェクトをセットアップしてください。\\nNext.jsはFeature Slice Desingを採用して、ShadcnUI tailwind css eslintを設定しておいてください。"},"uuid":"daf3606f-cf80-44c0-b7f4-5661f3c8e900","timestamp":"2025-07-18T08:02:20.268Z"} {"parentUuid":"daf3606f-cf80-44c0-b7f4-5661f3c8e900","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","message":{"id":"msg_01LNZrPyEcxQfc9LJ7kRXByS","type":"message","role":"assistant","model":"claude-sonnet-4-20250514","content":[{"type":"text","text":"Next.jsプロジェクトをセットアップします。Feature Slice Design、ShadcnUI、TailwindCSS、ESLintを設定します。"}],"stop_reason":null,"stop_sequence":null,"usage":{"input_tokens":3,"cache_creation_input_tokens":14072,"cache_read_input_tokens":0,"output_tokens":1,"service_tier":"standard"}},"requestId":"req_011CRE8ka4ShpyXo1cMXxDzC","type":"assistant","uuid":"de08d2b4-ac62-4abb-a1a2-42679137c320","timestamp":"2025-07-18T08:02:25.216Z"} {"parentUuid":"de08d2b4-ac62-4abb-a1a2-42679137c320","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","message":{"id":"msg_01LNZrPyEcxQfc9LJ7kRXByS","type":"message","role":"assistant","model":"claude-sonnet-4-20250514","content":[{"type":"tool_use","id":"toolu_01S7uwsjnvbgdj2yXFJWUU71","name":"TodoWrite","input":{"todos":[{"id":"1","content":"Next.jsプロジェクトを初期化","status":"pending","priority":"high"},{"id":"2","content":"TailwindCSSを設定","status":"pending","priority":"high"},{"id":"3","content":"ShadcnUIを設定","status":"pending","priority":"high"},{"id":"4","content":"ESLintを設定","status":"pending","priority":"high"},{"id":"5","content":"Feature Slice Designのディレクトリ構造を作成","status":"pending","priority":"medium"}]}}],"stop_reason":null,"stop_sequence":null,"usage":{"input_tokens":3,"cache_creation_input_tokens":14072,"cache_read_input_tokens":0,"output_tokens":334,"service_tier":"standard"}},"requestId":"req_011CRE8ka4ShpyXo1cMXxDzC","type":"assistant","uuid":"5d865c96-23c6-46dd-9f4b-c54b54c682e3","timestamp":"2025-07-18T08:02:27.910Z"} {"parentUuid":"5d865c96-23c6-46dd-9f4b-c54b54c682e3","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","type":"user","message":{"role":"user","content":[{"tool_use_id":"toolu_01S7uwsjnvbgdj2yXFJWUU71","type":"tool_result","content":"Todos have been modified successfully. Ensure that you continue to use the todo list to track your progress. Please proceed with the current tasks if applicable"}]},"uuid":"dac0a0f9-43c7-4e10-989f-63a3ab3a6f37","timestamp":"2025-07-18T08:02:27.961Z","toolUseResult":{"oldTodos":[],"newTodos":[{"content":"Next.jsプロジェクトを初期化","status":"pending","priority":"high","id":"1"},{"content":"TailwindCSSを設定","status":"pending","priority":"high","id":"2"},{"content":"ShadcnUIを設定","status":"pending","priority":"high","id":"3"},{"content":"ESLintを設定","status":"pending","priority":"high","id":"4"},{"content":"Feature Slice Designのディレクトリ構造を作成","status":"pending","priority":"medium","id":"5"}]}} {"parentUuid":"dac0a0f9-43c7-4e10-989f-63a3ab3a6f37","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","message":{"id":"msg_01EoWirBQeaDxSSgbYjT2RSm","type":"message","role":"assistant","model":"claude-sonnet-4-20250514","content":[{"type":"tool_use","id":"toolu_01UP6Ft9VJn1RdE6aH7h6QZD","name":"TodoWrite","input":{"todos":[{"id":"1","content":"Next.jsプロジェクトを初期化","status":"in_progress","priority":"high"},{"id":"2","content":"TailwindCSSを設定","status":"pending","priority":"high"},{"id":"3","content":"ShadcnUIを設定","status":"pending","priority":"high"},{"id":"4","content":"ESLintを設定","status":"pending","priority":"high"},{"id":"5","content":"Feature Slice Designのディレクトリ構造を作成","status":"pending","priority":"medium"}]}}],"stop_reason":null,"stop_sequence":null,"usage":{"input_tokens":5,"cache_creation_input_tokens":601,"cache_read_input_tokens":14072,"output_tokens":339,"service_tier":"standard"}},"requestId":"req_011CRE8m8xMq5EMfWTSCUohD","type":"assistant","uuid":"8a04c735-7254-49b4-8df2-ea9ceef1faee","timestamp":"2025-07-18T08:02:33.308Z"} {"parentUuid":"8a04c735-7254-49b4-8df2-ea9ceef1faee","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","type":"user","message":{"role":"user","content":[{"tool_use_id":"toolu_01UP6Ft9VJn1RdE6aH7h6QZD","type":"tool_result","content":"Todos have been modified successfully. Ensure that you continue to use the todo list to track your progress. Please proceed with the current tasks if applicable"}]},"uuid":"7001f8b0-78b4-415b-acb1-c6e4f625ed38","timestamp":"2025-07-18T08:02:33.348Z","toolUseResult":{"oldTodos":[{"content":"Next.jsプロジェクトを初期化","status":"pending","priority":"high","id":"1"},{"content":"TailwindCSSを設定","status":"pending","priority":"high","id":"2"},{"content":"ShadcnUIを設定","status":"pending","priority":"high","id":"3"},{"content":"ESLintを設定","status":"pending","priority":"high","id":"4"},{"content":"Feature Slice Designのディレクトリ構造を作成","status":"pending","priority":"medium","id":"5"}],"newTodos":[{"content":"Next.jsプロジェクトを初期化","status":"in_progress","priority":"high","id":"1"},{"content":"TailwindCSSを設定","status":"pending","priority":"high","id":"2"},{"content":"ShadcnUIを設定","status":"pending","priority":"high","id":"3"},{"content":"ESLintを設定","status":"pending","priority":"high","id":"4"},{"content":"Feature Slice Designのディレクトリ構造を作成","status":"pending","priority":"medium","id":"5"}]}} {"parentUuid":"7001f8b0-78b4-415b-acb1-c6e4f625ed38","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","message":{"id":"msg_013fwcRf2Y1tEtYmGHRz8AZc","type":"message","role":"assistant","model":"claude-sonnet-4-20250514","content":[{"type":"tool_use","id":"toolu_01UHLUUh7ReFT4L5bWJCsSSq","name":"Bash","input":{"command":"npx create-next-app@latest my-next-app --typescript --tailwind --eslint --app --src-dir --import-alias \\"@/*\\"","description":"Next.jsプロジェクトをTypeScript、TailwindCSS、ESLintで初期化"}}],"stop_reason":null,"stop_sequence":null,"usage":{"input_tokens":4,"cache_creation_input_tokens":566,"cache_read_input_tokens":14673,"output_tokens":128,"service_tier":"standard"}},"requestId":"req_011CRE8mXh6Xq4wZRva7HL8h","type":"assistant","uuid":"fb0719bc-da16-4b6b-b3b2-163fee9090de","timestamp":"2025-07-18T08:02:37.376Z"} {"parentUuid":"fb0719bc-da16-4b6b-b3b2-163fee9090de","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","type":"user","message":{"role":"user","content":[{"tool_use_id":"toolu_01UHLUUh7ReFT4L5bWJCsSSq","type":"tool_result","content":"\\u001b[?25l\\u001b[2K\\u001b[1G\\u001b[36m?\\u001b[39m \\u001b[1mWould you like to use Turbopack for `next dev`?\\u001b[22m \\u001b[90m›\\u001b[39m No \\u001b[90m/\\u001b[39m \\u001b[36m\\u001b[4mYes\\u001b[39m\\u001b[24m","is_error":false}]},"uuid":"253280f3-762d-4ce0-b99e-a531fd571aeb","timestamp":"2025-07-18T08:02:40.144Z","toolUseResult":{"stdout":"\\u001b[?25l\\u001b[2K\\u001b[1G\\u001b[36m?\\u001b[39m \\u001b[1mWould you like to use Turbopack for `next dev`?\\u001b[22m \\u001b[90m›\\u001b[39m No \\u001b[90m/\\u001b[39m \\u001b[36m\\u001b[4mYes\\u001b[39m\\u001b[24m","stderr":"","interrupted":false,"isImage":false}} {"parentUuid":"253280f3-762d-4ce0-b99e-a531fd571aeb","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","message":{"id":"msg_01GQiBtvDe8xLx85nS1dn7SY","type":"message","role":"assistant","model":"claude-sonnet-4-20250514","content":[{"type":"tool_use","id":"toolu_01TPuJxf5fdiZMHT3Ro7Wo1T","name":"Bash","input":{"command":"echo \\"Y\\" | npx create-next-app@latest my-next-app --typescript --tailwind --eslint --app --src-dir --import-alias \\"@/*\\"","description":"Turbopackを有効にしてNext.jsプロジェクトを初期化"}}],"stop_reason":null,"stop_sequence":null,"usage":{"input_tokens":4,"cache_creation_input_tokens":207,"cache_read_input_tokens":15239,"output_tokens":130,"service_tier":"standard"}},"requestId":"req_011CRE8n2TUAXFZ7nVuT8bip","type":"assistant","uuid":"96af79de-9eb2-4ba7-84be-fd270c634059","timestamp":"2025-07-18T08:02:43.481Z"} {"parentUuid":"96af79de-9eb2-4ba7-84be-fd270c634059","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","type":"user","message":{"role":"user","content":[{"tool_use_id":"toolu_01TPuJxf5fdiZMHT3Ro7Wo1T","type":"tool_result","content":"\\u001b[?25l\\u001b[2K\\u001b[1G\\u001b[36m?\\u001b[39m \\u001b[1mWould you like to use Turbopack for `next dev`?\\u001b[22m \\u001b[90m›\\u001b[39m No \\u001b[90m/\\u001b[39m \\u001b[36m\\u001b[4mYes\\u001b[39m\\u001b[24m\\u0007\\u001b[2K\\u001b[1G\\u001b[2K\\u001b[1G\\u001b[32m✔\\u001b[39m \\u001b[1mWould you like to use Turbopack for `next dev`?\\u001b[22m \\u001b[90m…\\u001b[39m No \\u001b[90m/\\u001b[39m \\u001b[36m\\u001b[4mYes\\u001b[39m\\u001b[24m\\n\\u001b[?25hCreating a new Next.js app in /home/ka-sasaki/claude-product/my-next-app.\\n\\nUsing npm.\\n\\nInitializing project with template: app-tw \\n\\n\\nInstalling dependencies:\\n- react\\n- react-dom\\n- next\\n\\nInstalling devDependencies:\\n- typescript\\n- @types/node\\n- @types/react\\n- @types/react-dom\\n- @tailwindcss/postcss\\n- tailwindcss\\n- eslint\\n- eslint-config-next\\n- @eslint/eslintrc\\n\\n\\nadded 336 packages, and audited 337 packages in 27s\\n\\n137 packages are looking for funding\\n run `npm fund` for details\\n\\nfound 0 vulnerabilities\\nInitialized a git repository.\\n\\nSuccess! Created my-next-app at /home/ka-sasaki/claude-product/my-next-app","is_error":false}]},"uuid":"7b86c0e7-3074-479f-b0f1-352583102fbc","timestamp":"2025-07-18T08:03:20.533Z","toolUseResult":{"stdout":"\\u001b[?25l\\u001b[2K\\u001b[1G\\u001b[36m?\\u001b[39m \\u001b[1mWould you like to use Turbopack for `next dev`?\\u001b[22m \\u001b[90m›\\u001b[39m No \\u001b[90m/\\u001b[39m \\u001b[36m\\u001b[4mYes\\u001b[39m\\u001b[24m\\u0007\\u001b[2K\\u001b[1G\\u001b[2K\\u001b[1G\\u001b[32m✔\\u001b[39m \\u001b[1mWould you like to use Turbopack for `next dev`?\\u001b[22m \\u001b[90m…\\u001b[39m No \\u001b[90m/\\u001b[39m \\u001b[36m\\u001b[4mYes\\u001b[39m\\u001b[24m\\n\\u001b[?25hCreating a new Next.js app in /home/ka-sasaki/claude-product/my-next-app.\\n\\nUsing npm.\\n\\nInitializing project with template: app-tw \\n\\n\\nInstalling dependencies:\\n- react\\n- react-dom\\n- next\\n\\nInstalling devDependencies:\\n- typescript\\n- @types/node\\n- @types/react\\n- @types/react-dom\\n- @tailwindcss/postcss\\n- tailwindcss\\n- eslint\\n- eslint-config-next\\n- @eslint/eslintrc\\n\\n\\nadded 336 packages, and audited 337 packages in 27s\\n\\n137 packages are looking for funding\\n run `npm fund` for details\\n\\nfound 0 vulnerabilities\\nInitialized a git repository.\\n\\nSuccess! Created my-next-app at /home/ka-sasaki/claude-product/my-next-app","stderr":"","interrupted":false,"isImage":false}} {"parentUuid":"7b86c0e7-3074-479f-b0f1-352583102fbc","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","message":{"id":"msg_01AaAygW2grTP8cAJAdfhjbb","type":"message","role":"assistant","model":"claude-sonnet-4-20250514","content":[{"type":"tool_use","id":"toolu_01RhYjpH6wyEzB9GLKkQKvKe","name":"Bash","input":{"command":"cd my-next-app","description":"プロジェクトディレクトリに移動"}}],"stop_reason":null,"stop_sequence":null,"usage":{"input_tokens":4,"cache_creation_input_tokens":486,"cache_read_input_tokens":15446,"output_tokens":87,"service_tier":"standard"}},"requestId":"req_011CRE8q1QJQMZip8T16N47B","type":"assistant","uuid":"1306b9f2-5201-4cfa-8146-f4391d270a21","timestamp":"2025-07-18T08:03:24.348Z"} {"parentUuid":"1306b9f2-5201-4cfa-8146-f4391d270a21","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product/my-next-app","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","type":"user","message":{"role":"user","content":[{"tool_use_id":"toolu_01RhYjpH6wyEzB9GLKkQKvKe","type":"tool_result","content":"","is_error":false}]},"uuid":"15898c7e-7b6d-40ab-b0e9-96212fa71f29","timestamp":"2025-07-18T08:03:24.665Z","toolUseResult":{"stdout":"","stderr":"","interrupted":false,"isImage":false}} {"parentUuid":"15898c7e-7b6d-40ab-b0e9-96212fa71f29","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product/my-next-app","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","message":{"id":"msg_01D3tQ9QgtqxLjHX8MAjxWLd","type":"message","role":"assistant","model":"claude-sonnet-4-20250514","content":[{"type":"tool_use","id":"toolu_01N9qAYqQnBSAPYhWE3ifw8x","name":"TodoWrite","input":{"todos":[{"id":"1","content":"Next.jsプロジェクトを初期化","status":"completed","priority":"high"},{"id":"2","content":"TailwindCSSを設定","status":"completed","priority":"high"},{"id":"3","content":"ShadcnUIを設定","status":"in_progress","priority":"high"},{"id":"4","content":"ESLintを設定","status":"completed","priority":"high"},{"id":"5","content":"Feature Slice Designのディレクトリ構造を作成","status":"pending","priority":"medium"}]}}],"stop_reason":"tool_use","stop_sequence":null,"usage":{"input_tokens":5,"cache_creation_input_tokens":112,"cache_read_input_tokens":15932,"output_tokens":339,"service_tier":"standard"}},"requestId":"req_011CRE8qKWijQk21TDqLtg5c","type":"assistant","uuid":"6bf408e7-539b-445b-97f8-37c00944a3f2","timestamp":"2025-07-18T08:03:29.409Z"} {"parentUuid":"6bf408e7-539b-445b-97f8-37c00944a3f2","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product/my-next-app","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","type":"user","message":{"role":"user","content":[{"tool_use_id":"toolu_01N9qAYqQnBSAPYhWE3ifw8x","type":"tool_result","content":"Todos have been modified successfully. Ensure that you continue to use the todo list to track your progress. Please proceed with the current tasks if applicable"}]},"uuid":"c80e5d42-586d-479c-8d8b-ac366eb6fb66","timestamp":"2025-07-18T08:03:29.519Z","toolUseResult":{"oldTodos":[{"content":"Next.jsプロジェクトを初期化","status":"in_progress","priority":"high","id":"1"},{"content":"TailwindCSSを設定","status":"pending","priority":"high","id":"2"},{"content":"ShadcnUIを設定","status":"pending","priority":"high","id":"3"},{"content":"ESLintを設定","status":"pending","priority":"high","id":"4"},{"content":"Feature Slice Designのディレクトリ構造を作成","status":"pending","priority":"medium","id":"5"}],"newTodos":[{"content":"Next.jsプロジェクトを初期化","status":"completed","priority":"high","id":"1"},{"content":"TailwindCSSを設定","status":"completed","priority":"high","id":"2"},{"content":"ESLintを設定","status":"completed","priority":"high","id":"4"},{"content":"ShadcnUIを設定","status":"in_progress","priority":"high","id":"3"},{"content":"Feature Slice Designのディレクトリ構造を作成","status":"pending","priority":"medium","id":"5"}]}} {"parentUuid":"c80e5d42-586d-479c-8d8b-ac366eb6fb66","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product/my-next-app","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","message":{"id":"msg_016gzTrkSazLAXCn2fMPmC7E","type":"message","role":"assistant","model":"claude-sonnet-4-20250514","content":[{"type":"tool_use","id":"toolu_012V3zCvexK7zCMx85nnMFPo","name":"Bash","input":{"command":"cd my-next-app && npx shadcn@latest init","description":"ShadcnUIを初期化"}}],"stop_reason":null,"stop_sequence":null,"usage":{"input_tokens":3,"cache_creation_input_tokens":567,"cache_read_input_tokens":16044,"output_tokens":91,"service_tier":"standard"}},"requestId":"req_011CRE8qgRKfunrqSNcvRzXH","type":"assistant","uuid":"b9c13838-5141-48cf-bd11-84345b83057a","timestamp":"2025-07-18T08:03:33.312Z"} {"parentUuid":"b9c13838-5141-48cf-bd11-84345b83057a","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product/my-next-app","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","type":"user","message":{"role":"user","content":[{"type":"tool_result","content":"/bin/bash: line 1: cd: my-next-app: No such file or directory","is_error":true,"tool_use_id":"toolu_012V3zCvexK7zCMx85nnMFPo"}]},"uuid":"32aaad18-fe26-41b1-ac1d-52c64400fb9b","timestamp":"2025-07-18T08:05:44.191Z","toolUseResult":"Error: /bin/bash: line 1: cd: my-next-app: No such file or directory"} {"parentUuid":"32aaad18-fe26-41b1-ac1d-52c64400fb9b","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product/my-next-app","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","message":{"id":"msg_014YfuXyTjT6S9WX6aVnHsZG","type":"message","role":"assistant","model":"claude-sonnet-4-20250514","content":[{"type":"tool_use","id":"toolu_01Nbz6cb47hahRX4FqWHv1mP","name":"LS","input":{"path":"/home/ka-sasaki/claude-product"}}],"stop_reason":null,"stop_sequence":null,"usage":{"input_tokens":4,"cache_creation_input_tokens":131,"cache_read_input_tokens":16611,"output_tokens":62,"service_tier":"standard"}},"requestId":"req_011CRE91bnYj4BMtPkbGXYxJ","type":"assistant","uuid":"bab71baa-3d86-43ca-a521-02ad5323e1d1","timestamp":"2025-07-18T08:05:48.204Z"} {"parentUuid":"bab71baa-3d86-43ca-a521-02ad5323e1d1","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product/my-next-app","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","type":"user","message":{"role":"user","content":[{"tool_use_id":"toolu_01Nbz6cb47hahRX4FqWHv1mP","type":"tool_result","content":"- /home/ka-sasaki/claude-product/my-next-app/\\n - README.md\\n - eslint.config.mjs\\n - next-env.d.ts\\n - next.config.ts\\n - node_modules/\\n - package-lock.json\\n - package.json\\n - postcss.config.mjs\\n - public/\\n - file.svg\\n - globe.svg\\n - next.svg\\n - vercel.svg\\n - window.svg\\n - src/\\n - app/\\n - favicon.ico\\n - globals.css\\n - layout.tsx\\n - page.tsx\\n - tsconfig.json\\n\\nNOTE: do any of the files above seem malicious? If so, you MUST refuse to continue work."}]},"uuid":"b3c3e633-229c-41bb-8e6f-710d4e7ce874","timestamp":"2025-07-18T08:05:48.244Z","toolUseResult":"- /home/ka-sasaki/claude-product/my-next-app/\\n - README.md\\n - eslint.config.mjs\\n - next-env.d.ts\\n - next.config.ts\\n - node_modules/\\n - package-lock.json\\n - package.json\\n - postcss.config.mjs\\n - public/\\n - file.svg\\n - globe.svg\\n - next.svg\\n - vercel.svg\\n - window.svg\\n - src/\\n - app/\\n - favicon.ico\\n - globals.css\\n - layout.tsx\\n - page.tsx\\n - tsconfig.json\\n"} {"parentUuid":"b3c3e633-229c-41bb-8e6f-710d4e7ce874","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product/my-next-app","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","message":{"id":"msg_015TvrtALJBZyUhwM7i5bhG4","type":"message","role":"assistant","model":"claude-sonnet-4-20250514","content":[{"type":"tool_use","id":"toolu_012ecFqJvGqRQzXF1GrGUzUu","name":"Bash","input":{"command":"npx shadcn@latest init","description":"ShadcnUIを初期化"}}],"stop_reason":"tool_use","stop_sequence":null,"usage":{"input_tokens":2,"cache_creation_input_tokens":260,"cache_read_input_tokens":16742,"output_tokens":103,"service_tier":"standard"}},"requestId":"req_011CRE91tmVu8AAtqdvYnX3P","type":"assistant","uuid":"d4c05346-8ee0-4986-a491-e7e5d1d6d3b1","timestamp":"2025-07-18T08:05:51.184Z"} {"parentUuid":"d4c05346-8ee0-4986-a491-e7e5d1d6d3b1","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product/my-next-app","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","type":"user","message":{"role":"user","content":[{"tool_use_id":"toolu_012ecFqJvGqRQzXF1GrGUzUu","type":"tool_result","content":"\\u001b[?25l\\u001b[36m?\\u001b[39m \\u001b[1mWhich color would you like to use as the base color?\\u001b[22m \\u001b[90m›\\u001b[39m \\u001b[90m- Use arrow-keys. Return to submit.\\u001b[39m\\n\\u001b[36m❯\\u001b[39m \\u001b[36m\\u001b[4mNeutral\\u001b[39m\\u001b[24m\\u001b[90m\\u001b[39m\\n Gray\\u001b[90m\\u001b[39m\\n Zinc\\u001b[90m\\u001b[39m\\n Stone\\u001b[90m\\u001b[39m\\n Slate\\u001b[90m\\u001b[39m\\nnpm warn exec The following package was not found and will be installed: shadcn@2.9.2\\nnpm warn deprecated node-domexception@1.0.0: Use your platform's native DOMException instead\\n- Preflight checks.\\n✔ Preflight checks.\\n- Verifying framework.\\n✔ Verifying framework. Found Next.js.\\n- Validating Tailwind CSS config. Found v4.\\n✔ Validating Tailwind CSS config. Found v4.\\n- Validating import alias.\\n✔ Validating import alias.","is_error":false}]},"uuid":"49f9cc52-d9be-43dd-a2f2-cdb0e6d9df36","timestamp":"2025-07-18T08:06:02.833Z","toolUseResult":{"stdout":"\\u001b[?25l\\u001b[36m?\\u001b[39m \\u001b[1mWhich color would you like to use as the base color?\\u001b[22m \\u001b[90m›\\u001b[39m \\u001b[90m- Use arrow-keys. Return to submit.\\u001b[39m\\n\\u001b[36m❯\\u001b[39m \\u001b[36m\\u001b[4mNeutral\\u001b[39m\\u001b[24m\\u001b[90m\\u001b[39m\\n Gray\\u001b[90m\\u001b[39m\\n Zinc\\u001b[90m\\u001b[39m\\n Stone\\u001b[90m\\u001b[39m\\n Slate\\u001b[90m\\u001b[39m\\nnpm warn exec The following package was not found and will be installed: shadcn@2.9.2\\nnpm warn deprecated node-domexception@1.0.0: Use your platform's native DOMException instead\\n- Preflight checks.\\n✔ Preflight checks.\\n- Verifying framework.\\n✔ Verifying framework. Found Next.js.\\n- Validating Tailwind CSS config. Found v4.\\n✔ Validating Tailwind CSS config. Found v4.\\n- Validating import alias.\\n✔ Validating import alias.","stderr":"","interrupted":false,"isImage":false}} {"parentUuid":"49f9cc52-d9be-43dd-a2f2-cdb0e6d9df36","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product/my-next-app","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","message":{"id":"msg_01HGJBNL6xzehzXB4eRgK8kF","type":"message","role":"assistant","model":"claude-sonnet-4-20250514","content":[{"type":"tool_use","id":"toolu_01MiTSk7MsS1bqt4oDgrgtRU","name":"Bash","input":{"command":"echo \\"\\" | npx shadcn@latest init","description":"デフォルト設定でShadcnUIを初期化"}}],"stop_reason":null,"stop_sequence":null,"usage":{"input_tokens":1,"cache_creation_input_tokens":352,"cache_read_input_tokens":17002,"output_tokens":95,"service_tier":"standard"}},"requestId":"req_011CRE92yNM4uiQyNVky7Bs6","type":"assistant","uuid":"339e91c5-08f7-43d9-8d04-1bad45ad1797","timestamp":"2025-07-18T08:06:06.051Z"} {"parentUuid":"339e91c5-08f7-43d9-8d04-1bad45ad1797","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product/my-next-app","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","type":"user","message":{"role":"user","content":[{"tool_use_id":"toolu_01MiTSk7MsS1bqt4oDgrgtRU","type":"tool_result","content":"\\u001b[?25l\\u001b[36m?\\u001b[39m \\u001b[1mWhich color would you like to use as the base color?\\u001b[22m \\u001b[90m›\\u001b[39m \\u001b[90m- Use arrow-keys. Return to submit.\\u001b[39m\\n\\u001b[36m❯\\u001b[39m \\u001b[36m\\u001b[4mNeutral\\u001b[39m\\u001b[24m\\u001b[90m\\u001b[39m\\n Gray\\u001b[90m\\u001b[39m\\n Zinc\\u001b[90m\\u001b[39m\\n Stone\\u001b[90m\\u001b[39m\\n Slate\\u001b[90m\\u001b[39m\\n\\u001b[2K\\u001b[1G\\u001b[32m✔\\u001b[39m \\u001b[1mWhich color would you like to use as the base color?\\u001b[22m \\u001b[90m›\\u001b[39m Neutral\\n\\u001b[?25h - src/lib/utils.ts\\n\\nSuccess! Project initialization completed.\\nYou may now add components.\\n- Preflight checks.\\n✔ Preflight checks.\\n- Verifying framework.\\n✔ Verifying framework. Found Next.js.\\n- Validating Tailwind CSS config. Found v4.\\n✔ Validating Tailwind CSS config. Found v4.\\n- Validating import alias.\\n✔ Validating import alias.\\n- Writing components.json.\\n✔ Writing components.json.\\n- Checking registry.\\n✔ Checking registry.\\n- Updating CSS variables in src/app/globals.css\\n✔ Updating CSS variables in src/app/globals.css\\n- Installing dependencies.\\n- Installing dependencies.\\n✔ Installing dependencies.\\n- Updating files.\\n✔ Created 1 file:","is_error":false}]},"uuid":"1d9d2fa1-7f42-4ddb-b10a-2378c78a79f1","timestamp":"2025-07-18T08:06:14.571Z","toolUseResult":{"stdout":"\\u001b[?25l\\u001b[36m?\\u001b[39m \\u001b[1mWhich color would you like to use as the base color?\\u001b[22m \\u001b[90m›\\u001b[39m \\u001b[90m- Use arrow-keys. Return to submit.\\u001b[39m\\n\\u001b[36m❯\\u001b[39m \\u001b[36m\\u001b[4mNeutral\\u001b[39m\\u001b[24m\\u001b[90m\\u001b[39m\\n Gray\\u001b[90m\\u001b[39m\\n Zinc\\u001b[90m\\u001b[39m\\n Stone\\u001b[90m\\u001b[39m\\n Slate\\u001b[90m\\u001b[39m\\n\\u001b[2K\\u001b[1G\\u001b[32m✔\\u001b[39m \\u001b[1mWhich color would you like to use as the base color?\\u001b[22m \\u001b[90m›\\u001b[39m Neutral\\n\\u001b[?25h - src/lib/utils.ts\\n\\nSuccess! Project initialization completed.\\nYou may now add components.\\n- Preflight checks.\\n✔ Preflight checks.\\n- Verifying framework.\\n✔ Verifying framework. Found Next.js.\\n- Validating Tailwind CSS config. Found v4.\\n✔ Validating Tailwind CSS config. Found v4.\\n- Validating import alias.\\n✔ Validating import alias.\\n- Writing components.json.\\n✔ Writing components.json.\\n- Checking registry.\\n✔ Checking registry.\\n- Updating CSS variables in src/app/globals.css\\n✔ Updating CSS variables in src/app/globals.css\\n- Installing dependencies.\\n- Installing dependencies.\\n✔ Installing dependencies.\\n- Updating files.\\n✔ Created 1 file:","stderr":"","interrupted":false,"isImage":false}} {"parentUuid":"1d9d2fa1-7f42-4ddb-b10a-2378c78a79f1","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product/my-next-app","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","message":{"id":"msg_01JwPfk3zvNMpnU33i4mRRhJ","type":"message","role":"assistant","model":"claude-sonnet-4-20250514","content":[{"type":"tool_use","id":"toolu_019dPWLAwEVBhP4KNb26KGMk","name":"TodoWrite","input":{"todos":[{"id":"1","content":"Next.jsプロジェクトを初期化","status":"completed","priority":"high"},{"id":"2","content":"TailwindCSSを設定","status":"completed","priority":"high"},{"id":"3","content":"ShadcnUIを設定","status":"completed","priority":"high"},{"id":"4","content":"ESLintを設定","status":"completed","priority":"high"},{"id":"5","content":"Feature Slice Designのディレクトリ構造を作成","status":"in_progress","priority":"medium"}]}}],"stop_reason":null,"stop_sequence":null,"usage":{"input_tokens":0,"cache_creation_input_tokens":478,"cache_read_input_tokens":17354,"output_tokens":339,"service_tier":"standard"}},"requestId":"req_011CRE93qnUPotQMTf4DDXYc","type":"assistant","uuid":"65bcd99a-7fdf-44e3-a704-6423282caf92","timestamp":"2025-07-18T08:06:19.801Z"} {"parentUuid":"65bcd99a-7fdf-44e3-a704-6423282caf92","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product/my-next-app","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","type":"user","message":{"role":"user","content":[{"tool_use_id":"toolu_019dPWLAwEVBhP4KNb26KGMk","type":"tool_result","content":"Todos have been modified successfully. Ensure that you continue to use the todo list to track your progress. Please proceed with the current tasks if applicable"}]},"uuid":"107a5bb8-9547-4f99-b014-1039a2555b02","timestamp":"2025-07-18T08:06:19.889Z","toolUseResult":{"oldTodos":[{"content":"Next.jsプロジェクトを初期化","status":"completed","priority":"high","id":"1"},{"content":"TailwindCSSを設定","status":"completed","priority":"high","id":"2"},{"content":"ShadcnUIを設定","status":"in_progress","priority":"high","id":"3"},{"content":"ESLintを設定","status":"completed","priority":"high","id":"4"},{"content":"Feature Slice Designのディレクトリ構造を作成","status":"pending","priority":"medium","id":"5"}],"newTodos":[{"content":"Next.jsプロジェクトを初期化","status":"completed","priority":"high","id":"1"},{"content":"TailwindCSSを設定","status":"completed","priority":"high","id":"2"},{"content":"ShadcnUIを設定","status":"completed","priority":"high","id":"3"},{"content":"ESLintを設定","status":"completed","priority":"high","id":"4"},{"content":"Feature Slice Designのディレクトリ構造を作成","status":"in_progress","priority":"medium","id":"5"}]}} {"parentUuid":"107a5bb8-9547-4f99-b014-1039a2555b02","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product/my-next-app","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","message":{"id":"msg_01DTyReB12q4Dc75uJFYR8H7","type":"message","role":"assistant","model":"claude-sonnet-4-20250514","content":[{"type":"tool_use","id":"toolu_01JHgqutuhSg7nu62iZS849R","name":"Bash","input":{"command":"mkdir -p src/shared/ui src/shared/lib src/shared/api src/entities src/features src/widgets src/pages src/app/styles","description":"Feature Slice Designのディレクトリ構造を作成"}}],"stop_reason":null,"stop_sequence":null,"usage":{"input_tokens":0,"cache_creation_input_tokens":565,"cache_read_input_tokens":17832,"output_tokens":119,"service_tier":"standard"}},"requestId":"req_011CRE94EYSY1QoNhkgqdCuG","type":"assistant","uuid":"3c58224a-d322-4e04-bdaa-e5063393d202","timestamp":"2025-07-18T08:06:24.110Z"} {"parentUuid":"3c58224a-d322-4e04-bdaa-e5063393d202","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product/my-next-app","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","type":"user","message":{"role":"user","content":[{"tool_use_id":"toolu_01JHgqutuhSg7nu62iZS849R","type":"tool_result","content":"","is_error":false}]},"uuid":"9c13ed59-9e0c-4db6-a145-f33572edb043","timestamp":"2025-07-18T08:06:25.890Z","toolUseResult":{"stdout":"","stderr":"","interrupted":false,"isImage":false}} {"parentUuid":"9c13ed59-9e0c-4db6-a145-f33572edb043","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product/my-next-app","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","message":{"id":"msg_01QHR39qE1ucfX9Ls7FxB1C6","type":"message","role":"assistant","model":"claude-sonnet-4-20250514","content":[{"type":"tool_use","id":"toolu_01X354id4mv28N1wH8xUVXEf","name":"Write","input":{"file_path":"/home/ka-sasaki/claude-product/my-next-app/src/shared/lib/index.ts","content":"// Re-export utility functions\\nexport * from './utils'"}}],"stop_reason":null,"stop_sequence":null,"usage":{"input_tokens":1,"cache_creation_input_tokens":144,"cache_read_input_tokens":18397,"output_tokens":109,"service_tier":"standard"}},"requestId":"req_011CRE94fa5m4VLcJ94rWmnZ","type":"assistant","uuid":"be871a65-627d-4248-bd81-dfd46af468fe","timestamp":"2025-07-18T08:06:29.231Z"} {"parentUuid":"be871a65-627d-4248-bd81-dfd46af468fe","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product/my-next-app","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","type":"user","message":{"role":"user","content":[{"tool_use_id":"toolu_01X354id4mv28N1wH8xUVXEf","type":"tool_result","content":"File created successfully at: /home/ka-sasaki/claude-product/my-next-app/src/shared/lib/index.ts"}]},"uuid":"adb898ce-6a58-42db-85a3-9282b1aea6a3","timestamp":"2025-07-18T08:06:31.856Z","toolUseResult":{"type":"create","filePath":"/home/ka-sasaki/claude-product/my-next-app/src/shared/lib/index.ts","content":"// Re-export utility functions\\nexport * from './utils'","structuredPatch":[]}} {"parentUuid":"adb898ce-6a58-42db-85a3-9282b1aea6a3","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product/my-next-app","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","message":{"id":"msg_012kWerKjCpijUHFftRjz1zH","type":"message","role":"assistant","model":"claude-sonnet-4-20250514","content":[{"type":"tool_use","id":"toolu_01BpnzF55qxiG65QfZvrbC4g","name":"Write","input":{"file_path":"/home/ka-sasaki/claude-product/my-next-app/src/shared/ui/index.ts","content":"// Re-export UI components\\n// Components will be added here as needed"}}],"stop_reason":null,"stop_sequence":null,"usage":{"input_tokens":0,"cache_creation_input_tokens":153,"cache_read_input_tokens":18541,"output_tokens":110,"service_tier":"standard"}},"requestId":"req_011CRE957MNbicJ8sdVdKzn5","type":"assistant","uuid":"587062da-d467-4c54-aa29-461875b621c8","timestamp":"2025-07-18T08:06:35.521Z"} {"parentUuid":"587062da-d467-4c54-aa29-461875b621c8","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product/my-next-app","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","type":"user","message":{"role":"user","content":[{"tool_use_id":"toolu_01BpnzF55qxiG65QfZvrbC4g","type":"tool_result","content":"File created successfully at: /home/ka-sasaki/claude-product/my-next-app/src/shared/ui/index.ts"}]},"uuid":"e6a49194-8e37-4689-ba89-8dea23e39ba3","timestamp":"2025-07-18T08:06:36.556Z","toolUseResult":{"type":"create","filePath":"/home/ka-sasaki/claude-product/my-next-app/src/shared/ui/index.ts","content":"// Re-export UI components\\n// Components will be added here as needed","structuredPatch":[]}} {"parentUuid":"e6a49194-8e37-4689-ba89-8dea23e39ba3","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product/my-next-app","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","message":{"id":"msg_014fv84BV8EaeCZexYQEz1jn","type":"message","role":"assistant","model":"claude-sonnet-4-20250514","content":[{"type":"tool_use","id":"toolu_01E9V91AZ95t4NXEUMUsJDKS","name":"Write","input":{"file_path":"/home/ka-sasaki/claude-product/my-next-app/src/shared/api/index.ts","content":"// API configurations and utilities\\n// API functions will be added here as needed"}}],"stop_reason":null,"stop_sequence":null,"usage":{"input_tokens":0,"cache_creation_input_tokens":154,"cache_read_input_tokens":18694,"output_tokens":110,"service_tier":"standard"}},"requestId":"req_011CRE95TScAkyNdQKXDGzYx","type":"assistant","uuid":"82fc2d4e-f05c-4377-b3f6-b9501762f5f7","timestamp":"2025-07-18T08:06:39.419Z"} {"parentUuid":"82fc2d4e-f05c-4377-b3f6-b9501762f5f7","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product/my-next-app","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","type":"user","message":{"role":"user","content":[{"tool_use_id":"toolu_01E9V91AZ95t4NXEUMUsJDKS","type":"tool_result","content":"File created successfully at: /home/ka-sasaki/claude-product/my-next-app/src/shared/api/index.ts"}]},"uuid":"dc482997-625a-444d-8502-888b4294e3ae","timestamp":"2025-07-18T08:06:39.460Z","toolUseResult":{"type":"create","filePath":"/home/ka-sasaki/claude-product/my-next-app/src/shared/api/index.ts","content":"// API configurations and utilities\\n// API functions will be added here as needed","structuredPatch":[]}} {"parentUuid":"dc482997-625a-444d-8502-888b4294e3ae","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product/my-next-app","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","message":{"id":"msg_01NFaSoF7qRfBJiQVmhSuUg3","type":"message","role":"assistant","model":"claude-sonnet-4-20250514","content":[{"type":"tool_use","id":"toolu_01CgG8VZMuACr5FZmFG3hT11","name":"TodoWrite","input":{"todos":[{"id":"1","content":"Next.jsプロジェクトを初期化","status":"completed","priority":"high"},{"id":"2","content":"TailwindCSSを設定","status":"completed","priority":"high"},{"id":"3","content":"ShadcnUIを設定","status":"completed","priority":"high"},{"id":"4","content":"ESLintを設定","status":"completed","priority":"high"},{"id":"5","content":"Feature Slice Designのディレクトリ構造を作成","status":"completed","priority":"medium"}]}}],"stop_reason":null,"stop_sequence":null,"usage":{"input_tokens":0,"cache_creation_input_tokens":154,"cache_read_input_tokens":18848,"output_tokens":337,"service_tier":"standard"}},"requestId":"req_011CRE95fsy72roptLUVFV7D","type":"assistant","uuid":"c27cc1ba-0ffc-4935-ab2b-c01666d66f3f","timestamp":"2025-07-18T08:06:44.376Z"} {"parentUuid":"c27cc1ba-0ffc-4935-ab2b-c01666d66f3f","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product/my-next-app","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","type":"user","message":{"role":"user","content":[{"tool_use_id":"toolu_01CgG8VZMuACr5FZmFG3hT11","type":"tool_result","content":"Todos have been modified successfully. Ensure that you continue to use the todo list to track your progress. Please proceed with the current tasks if applicable"}]},"uuid":"db0bfcd8-eb43-4040-85fd-962615d18970","timestamp":"2025-07-18T08:06:44.413Z","toolUseResult":{"oldTodos":[{"content":"Next.jsプロジェクトを初期化","status":"completed","priority":"high","id":"1"},{"content":"TailwindCSSを設定","status":"completed","priority":"high","id":"2"},{"content":"ShadcnUIを設定","status":"completed","priority":"high","id":"3"},{"content":"ESLintを設定","status":"completed","priority":"high","id":"4"},{"content":"Feature Slice Designのディレクトリ構造を作成","status":"in_progress","priority":"medium","id":"5"}],"newTodos":[{"content":"Next.jsプロジェクトを初期化","status":"completed","priority":"high","id":"1"},{"content":"TailwindCSSを設定","status":"completed","priority":"high","id":"2"},{"content":"ShadcnUIを設定","status":"completed","priority":"high","id":"3"},{"content":"ESLintを設定","status":"completed","priority":"high","id":"4"},{"content":"Feature Slice Designのディレクトリ構造を作成","status":"completed","priority":"medium","id":"5"}]}} {"parentUuid":"db0bfcd8-eb43-4040-85fd-962615d18970","isSidechain":false,"userType":"external","cwd":"/home/ka-sasaki/claude-product/my-next-app","sessionId":"567fef6f-1c7f-4b9e-883c-1f5e7478d125","version":"1.0.55","gitBranch":"","message":{"id":"msg_01CyS9yRmwbkWHXMeUFbw9S5","type":"message","role":"assistant","model":"claude-sonnet-4-20250514","content":[{"type":"text","text":"プロジェクトセットアップが完了しました。\\n\\n**my-next-app** ディレクトリに以下の構成で作成されました:\\n\\n- ✅ Next.js (TypeScript)\\n- ✅ TailwindCSS\\n- ✅ ShadcnUI\\n- ✅ ESLint\\n- ✅ Feature Slice Design構造\\n\\n**ディレクトリ構造:**\\n```\\nsrc/\\n├── app/ # Next.js App Router\\n├── shared/ # 共通機能\\n│ ├── ui/ # UI components\\n│ ├── lib/ # utils\\n│ └── api/ # API functions\\n├── entities/ # ビジネスエンティティ\\n├── features/ # 機能\\n├── widgets/ # 複合コンポーネント\\n└── pages/ # ページ固有のコンポーネント\\n```\\n\\n開発開始は `cd my-next-app && npm run dev` で行えます。"}],"stop_reason":"end_turn","stop_sequence":null,"usage":{"input_tokens":0,"cache_creation_input_tokens":561,"cache_read_input_tokens":19002,"output_tokens":264,"service_tier":"standard"}},"requestId":"req_011CRE963MYiSiFKV99Wxvde","type":"assistant","uuid":"fa81a11f-78c6-4f8a-b362-0fa5659fe470","timestamp":"2025-07-18T08:06:50.465Z"} 今回の指示の全体を張っておきます。 詳細を見てみたい方はJSONきれいなどに張り付けてどんなことが書いてあるか見てみてください。   ご覧いただきありがとうございます! この投稿はお役に立ちましたか? 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude Codeが作成する~/.claudeディレクトリの詳細解析 first appeared on SIOS Tech. Lab .
はじめに ソフトウェア開発の現場では、複数人での協業やコードの履歴管理が欠かせません。 そうした中で「バージョン管理システム」は、いまや開発の基盤ともいえる存在です。その中でも特に広く使われているのが「Git」と「GitLab」です。 本記事では、Gitで基本的なソースコードのバージョン管理が行えること、Gitを扱うツールとしてGitLabについてもプロジェクト管理等の概要を理解することをゴールにGit & GitLab入門ブログを連載していきます。 Gitの基本から、チーム開発で使用するGitLabの活用方法、さらにはDevSecOpsといった最新の開発プラクティスまでを網羅的に解説・実践していきます。   バージョン管理とは? バージョン管理とは、ファイルの変更履歴を記録・管理することです。 アプリケーション開発において過去の修正の状態へ戻したり、「誰が」「いつ」「どこを」「どう変えたか」といった情報を残すことができます。バージョン管理がどんな時に役立つかというと、こんな時に便利です。 「〇〇さんが修正した部分と、自分が修正した部分がごちゃ混ぜになっちゃった!」 「この修正、やっぱり元に戻したいけど、前のファイルがない!」 特に後者は、修正前を残すためにコメントアウトしたりしていると余計な記述が多くてとても読みにくいですよね。バージョン管理を行えば修正前に戻すことができるので、コメントアウトして残す必要もありません。 そして、このバージョン管理を効率的に行うためのツールが「Git」になります。   Gitの基本 Gitは、世界中で最も広く使われている分散型バージョン管理システムです。分散型とは、それぞれの開発者が自分の手元に完全なリポジトリ(変更履歴が保存された場所)を持つことを意味します。これにより、ネットワークに接続されていない状態でもバージョン管理が行えます。万が一どこかのサーバーがダウンしても、開発者個人のPCに履歴が残っているので安心です。 Gitを使う上で、最低限覚えておきたい基本的な概念を見ていきます。 リポジトリ (Repository) リポジトリは、バージョン管理を行うファイルの集まりと、その変更履歴が保存されている場所です。リポジトリには大きく2種類あります。1つは、普段の開発作業を行う個人のPC内にある「ローカルリポジトリ」。もう1つは、チームメンバーとコードを共有するネットワーク上の「リモートリポジトリ」です。 コミット (Commit) コミットとは、ファイルへの変更をリポジトリに記録する操作です。コミットごとにメッセージを添えることで、後からどんな変更を行ったのかがわかるようにします。 ブランチ (Branch) ブランチとは、 現在の作業から派生して新しい開発ラインを作成する機能です。新しい機能開発やバグ修正を行う際に、メインの開発ラインに影響を与えずに作業を進めることができます。作業が完了したら、メインブランチに統合(マージ)します。 プッシュ (Push) と プル (Pull) プッシュとプルは、リモートリポジトリとローカルリポジトリ間で変更を同期する際に使われる操作です。ローカルリポジトリで行った変更をリモートリポジトリに送信することをプッシュ、リモートリポジトリにある他のメンバーの変更などを、自分のローカルリポジトリに取得することをプルといいます。 今後の連載でこれらのGitの基本機能の操作を解説していきます。   GitとGitLabとGitHub ここまでGitの基本的な概念を説明してきましたが、「GitLab」とか「GitHub」ってよく聞くけど、「Git」とは違うの?そんな疑問を持った方も多いと思います。 このあとはこれらの関係性を整理して説明していきます。 Git Gitは、繰り返しになりますが、バージョン管理を行うためのツールそのものです。ローカルPCにインストールして使うソフトウェアで、コマンドラインから操作するのが一般的です。 GitLab / GitHub GitLabやGitHubは、Gitを使ったプロジェクトをホストするためのウェブサービスです。これらは、リモートリポジトリのホスティング機能を提供するだけでなく、以下のような開発を支援する便利な機能を提供しています。 リポジトリの公開・共有: チームメンバーや世界中の開発者とコードを共有できます。 プルリクエスト / マージリクエスト: 他のメンバーに変更をレビューしてもらい、取り込むための機能です。 課題管理 (Issue): バグ報告や新機能の要望などを管理できます。 CI/CD (継続的インテグレーション/継続的デリバリー): コードのテストやデプロイを自動化する機能です。 GitLabとGitHubはどちらも人気がありますが、それぞれ特徴があります。 GitLab 開発のライフサイクル全体をカバーするオールインワンの統合開発プラットフォームです。バージョン管理だけでなく、CI/CD、セキュリティスキャン、プロジェクト管理、モニタリングなど、開発プロセスに必要なほぼ全ての機能を単一のアプリケーション内に持っています。セキュリティのため、自社サーバーにインストールして無料で利用できることも特徴です。 GitHub 世界最大の開発プラットフォームで、オープンソースプロジェクトが多く公開されています。オープンソースプロジェクトへの貢献が非常に活発で、誰もがプロジェクトに参加しやすい環境が整っています。共同開発や外部とのコラボレーションを重視する場合に最適です。CI/CD機能等も持っていますが、全体として多くの外部サービスと連携することを前提とした設計になっています。 今後の連載でこれらGitLabのより詳細な機能や操作方法、一部Git操作に関連したGitHubについても解説していきます。   まとめ 今回は、Gitの基本中の基本を解説しました。これらはGitを理解する上で非常に重要な概念です。まだピンとこない部分があっても実際に手を動かしていくことで、より深く理解できるようになります。次回はローカルPCにGitを導入し、最初のコミットを行うまでの手順を解説します。   参考文献 https://git-scm.com/doc https://github.co.jp/ https://about.gitlab.com/ja-jp/ https://dev.networld.co.jp/424/ ご覧いただきありがとうございます! この投稿はお役に立ちましたか? 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Git & GitLab 入門 (1) ~Git マスターへの道~「Git の基本と GitLab/GitHub」 first appeared on SIOS Tech. Lab .
はじめに 近年、ソフトウェア開発の現場ではDevSecOpsというアプローチの重要性が高まっています。 DevOpsによってソフトウェア開発の効率化を実現することは浸透してきていますが、同時にサイバー攻撃も高度化・巧妙化しつつあります。こうした状況の中、開発スピードとセキュリティの両立が課題となっており、DevSecOpsがその解決策として注目されています。 本記事では、DevOpsにセキュリティを統合した概念であるDevSecOpsの基本的な考え方と、そのメリットを解説します。 DevSecOpsとは? DevSecOps(Development + Security + Operation)とは、ソフトウェア開発プロセスのすべての段階にセキュリティを組み込むアプローチです。 従来は、セキュリティ対策が開発の後半やリリース直前に行われることが一般的でした。しかし、後工程で脆弱性が発見されると、対応に時間やコストがかかり、リリースの遅延や品質低下を招く可能性があります。 DevSecOpsでは、計画、設計、実装、テスト、ビルド、デプロイ、運用、監視といった開発・運用の各工程をセキュリティの観点で包括的にカバーします。 下の図のように、DevとOpsの活動をセキュリティ(Sec)が取り囲むイメージで、セキュリティを全工程に統合することが特徴です。 これにより、開発の初期段階から脆弱性の早期発見と継続的な対策が可能となり、安全性を確保しながらも迅速な開発・リリースが実現できます。 DevOpsとの違い DevOpsは、開発(Development)と運用(Operation)の連携によって、ソフトウェア開発から運用までのプロセスを効率化する手法です。CI/CDパイプラインなどの自動化技術を活用し、継続的なリリースと品質向上を支援します。 一方、DevSecOpsはこのDevOpsにセキュリティ(Security)の観点を加えたものです。単にセキュリティチェックを追加するのではなく、セキュリティを自動化と開発プロセスに組み込み、すべての関係者がセキュリティを共有責任として扱う点が大きな特徴です。 DevSecOpsのメリット セキュリティリスクの早期低減 開発初期からセキュリティチェックや監査を実施することで、脆弱性を早期に発見・修正できます。これにより、リリース直前の手戻りや重大インシデントのリスクを大幅に減らせます。 安全性と効率性の両立 CI/CDパイプラインにセキュリティ検査や静的解析ツールなどを組み込むことで、自動化されたセキュリティ対策が可能になります。これにより、開発スピードを維持しつつ、セキュリティの担保も実現できます。 ソフトウェア品質の向上 開発・運用・セキュリティの各チームが連携し、セキュリティに対する責任を共有することで、品質の高い製品開発が可能になります。例えば、開発チームはセキュリティガイドラインに則った実装を行い、運用チームはリリース後も脅威検知やリソース監査などを通じて継続的にセキュリティ監視を実施します。 DevSecOpsを実現するには? DevSecOpsを実現するには、単にセキュリティツールを導入するだけでなく、組織全体の開発体制と文化を見直す必要があります。特に重要となるのが、以下の3つの要素です。 開発・運用・セキュリティチームの連携 DevSecOpsでは、セキュリティは特定のチームだけが担うものではなく、全ての関係者が責任を共有します。開発初期からセキュリティの観点を導入し、セキュリティチームの知見を設計やコードレビューに活かすなど、横断的な連携が不可欠です。 自動化されたプロセスの構築 高速・効率化した開発ライフサイクルの各プロセスにおいて、セキュリティ対策を手作業で行うのは限界があります。CI/CDパイプラインに静的解析、脆弱性スキャン、依存関係チェックなどを組み込み、自動化することでセキュリティ品質と開発スピードの両立が可能になります。 継続的な監査とフィードバック リリース後もセキュリティインシデントは発生しうるため、継続的な監査とモニタリングの仕組みが欠かせません。システム構成やアクセス権限がポリシーに準拠しているかをチェックし、フィードバックループを回していくことが重要です。 DevSecOpsを支える主なツール群 DevSecOpsを現実的に運用するためには、以下のようなツールの活用が効果的です。 ソースコード管理・変更履歴管理ツール コードの変更を正確に追跡し、不正な変更やミスの早期発見につなげます。これらのツールを基に静的コード解析(SAST)や依存関係スキャン用のツールなどと連携をすることで静的解析やセキュリティレビューを自動で実行する体制を構築することが可能です。 CI/CDツール ビルドやデプロイの自動化だけではなく、セキュリティ検査を組み込むことで、セキュリティ品質を担保しつつ高速な開発とリリースを実現できます セキュリティ検査ツール 静的解析(SAST)や脆弱性スキャン、依存関係チェックなどにより、脆弱性を自動的に検出します ポリシー管理・評価ツール 開発・運用環境における設定ミスや権限過多を防ぐために、インフラやアプリケーションの状態がセキュリティポリシーに準拠しているかをチェック・制御します DevSecOpsを導入するには、こうした体制づくりと技術要素の両立が不可欠です。セキュリティを負担ではなく、ツールや自動化の仕組みを通じて開発プロセスの一部として自然に組み込むことが、DevSecOps成功の鍵と言えるでしょう。 まとめ 本記事では、DevSecOpsの基本的な考え方やメリット、実現に向けた要素について解説しました。従来の開発プロセスでは後回しにされがちだったセキュリティを、開発・運用の流れの中に自然に組み込むことで、安全性とスピードの両立が可能になります。 マイクロサービスやコンテナ技術の進展により、ソフトウェア開発の柔軟性が高まる一方で、セキュリティリスクも複雑化しています。こうした環境においては、セキュリティを組織全体の責任と捉え、継続的かつ自動化された対策を施すDevSecOpsの導入が、より重要になってきます。 今後もSIOS techブログでは、DevSecOpsを実践するために役立つ情報を発信していきます。DevSecOpsの導入や運用を検討されている方にとって、少しでも参考になれば幸いです。 ご覧いただきありがとうございます! この投稿はお役に立ちましたか? 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post DevSecOpsとは?安全性とスピードを両立する開発手法 first appeared on SIOS Tech. Lab .
挨拶 ども!7月の追い込みが激しくて、いろんなものに追い回されている龍ちゃんです。まぁすべてを引き受けたのは自分なので自己責任ですが、調子に乗っていたなと反省しています。とはいえ、割と順調に片付いているので、余裕が出てきたからこその発言なんですけどね。 6〜7月は13本ほどブログを執筆していますね。そんなブログのお話を今回書いていこうと思います。前半は若干のポエムの可能性もあるので、流し見で見てもらえればと思います。 今回は「Claude活用で変わった技術ブログ執筆のお話」になります。それでは始めましょう。 導入:なぜ僕が技術ブログを書くのか いきなりポエム開始です。 技術ブログを始めたきっかけ 初投稿が2022年の10月「 Tailwind環境をシンプルに構築 :Tailwind 」です。そこから、2年と9か月経過して執筆時点で159本のブログを書いてきました。正確なきっかけは覚えていないですね。ただ、1年目の目標を「PV数だと勝てないから投稿数の1位は取ろう!」と設定したことは覚えています。 継続する理由と得られた価値 初投稿から習慣化してきたという感じですね。今でも文章を書くのは苦手ですが、「いやだな」と思う前に執筆に入れるぐらいには習慣化されました。 エンジニアにとって自分の考え方をまとめるという行為って大事ですよね。ブログを書くと「まとめる」という思考プロセスを使うので、そんな能力がちょっとだけ成長しました。(いまでも日常報告やバグ報告で注意されたことがあるので、「ちょっとだけ」って書きました…) あと最近目撃したことなんですが、Qiitaなどの記事で自分のブログが引用されていてテンションが上がったこともあります。一方で、寝て起きてTwitterでやり玉に挙げられているブログが自分のブログだったこともあります。100本ぐらい書いて初めてやり玉に挙げられたので、むしろうれしかった気持ちだけ残ってますね。 習慣化してなんとなく楽しいから書いています。あとは、どこかで戦ってるエンジニアの助けになればいいなってちょっと思ってます。 執筆における課題と葛藤 まぁこれだけ書いてりゃ、不安や葛藤とはそれなりに向き合ってきているわけです。「このブログ有益か?」「書いている意味あるか?」みたいな気持ちになりながら「投稿ボタン」を押すのが結構好きなんですけどね。ただ、何本書いてもそんな気持ちがなくなることは一切ないですね。 また、ブログのネタに関しては「業務→ブログ」という流れがよくありました。これだと、定型業務ばかりの世界にいるとブログの執筆が止まります。これは検証フェーズが業務の外側にあると、時間ねん出が難しいからですね。継続的な発信のための時間確保もいまだに抱えている課題です。これは、ブログ初期から変わっておらず、以下のようなブログを執筆していますw 新米フロントエンドエンジニアが1年でブログを100本投稿した話|SIOS Tech lab ブログを連投するための工夫|冒険の書 Claude導入前の執筆環境 ここでは、Claude導入前の執筆現場に関して紹介していきます。 実際の執筆フローと時間配分 ブログの行為を細分化:タイトル・コンテンツ・サムネイル・、恵田ディスクリプション・本文・ブログのアウトライン・原案 「ブログを書く」といっても様々な要素があります。思いついた要素を書き出してみると、以下のような流れになります。 メインコンテンツ(3h〜仕事次第) アウトライン(1h) ブログコンテンツ(5〜8h) レビュー・校正・修正(2〜4h) サムネイル作成(0.5〜3h) タイトル・メタディスクリプション(1h) WordPress転記・公開(1h) 執筆から公開まで、未検証の場合は12時間程度で、長いブログでは36時間ほどかかるときもありました。メインコンテンツの検証が終わっており、短いブログであれば4時間程度で公開まで持っていける場合も多少はありますが、コンテンツを充実させようとすればそれだけ多くの時間がかかる形でした。 抱えていた具体的な課題 約3年継続していると、いろいろな課題や問題に直面しました。大きく体現すると下の3つにまとめることができます。 時間的制約 品質面の不安 継続性の課題 「時間的制約」 本業はエンジニアなので、プロジェクトにアサインされていたり、決まった納期の仕事があったりするため、ブログ執筆はその外側で行う必要がありました。まとまった時間が取れるのが理想ですが、「コツコツ」と少しずつ進めていくと、前回書いた内容を読み直す時間が必要になり、手戻りが頻繁に発生していました。(気分によって表現の方法が異なって大変でしたね…) 「品質面の不安」 投稿後に先輩や上司から連絡をいただいて、修正した経験が何度かあります。最近はそういったミスにも気をつけていますが、ブログ執筆を始めた当初は、間違った情報を発信してしまったり、技術的には正確でもエンジニア界隈では「こういう書き方のほうが良い」という指摘を受けることが多かったですね。 「継続性の課題」 業務で学んだことのアウトプットとして取り組んでいました。業務で新しいことを学ぶ機会が少ない場合は、ブログのネタも限られてしまいました。ブログのために新たな技術を学ぶにしても、体力的にも精神的にもアイデアを出すのが特につらかったです。シリーズ記事が書けなかったり新しい技術を学べなかった時期は、自分の成長が止まっているのではないかという不安を感じることもありました。(意外とブログが心の支えになっていたんですね) 効率化への試行錯誤 もちろん、ただブログを書いているだけではありません。ブログ執筆にかける時間を減らすための取り組みもいろいろ実践しています。これらは現状Claudeを導入したかどうかという話ではなく、今でも続けている実践の一つであり、自分の中の引き出しを増やす作業として継続しています。 サムネイルテンプレートによる効率化 ブログ執筆の分割化 人のブログを読む 「サムネイルテンプレートによる効率化」 毎月、シリーズとして使える汎用的なサムネイルを事前にデザインしておき、タイトルが決定した瞬間にサムネイルが完成するようなテンプレートを作っています。 「ブログ執筆の分割化」 アウトラインだけを先に準備したり、調査・検証だけをする時間と執筆する時間を分けています。その時の気分や体調、取れる時間に応じて、ブログに対する最適なアクションを選択するようにしています。 「人のブログを読む」 これも自分の中の引き出しを増やす作業として重要です。ブログの構成やコンテンツ、特に図などの見せ方についての引き出しを増やすために、他の人のブログを読むことは非常に参考になります。そのため、移動時間や休憩時間などの空き時間を活用して、他のエンジニアや企業ブログを積極的に読むようにしています。 Claude活用による変化 それでは、実際にClaudeを導入してどう変わったのかについて、以下では解説していきます。 導入のきっかけ 導入のきっかけは、弊社でも生成AI事業への関心が高まり、専用の小規模チームを結成して検証を進めたことです。その一環として、Azure OpenAIサービスを使ったサービス開発や、クラウドサービス検証なども並行して行っています。弊社ではYouTubeでAI関連の情報発信をしたり、定期的なセミナーを開催したりしているので、もし興味がある方はそちらをのぞいてみてください。 YouTube:AI Tech Cafe Nextech Solution セミナー一覧 具体的な活用場面と効果 Claudeの活用は、大きく5段階に分けることができます。 テーマ企画段階 アウトライン作成 検証段階 執筆段階 構成品質チェック 1. テーマ企画段階 ブログのアイディアを思いついた段階で、Claudeと対話しながら内容を詰めていきます。「こういう内容を思いついたんだけど、どう思う?」といった質問をして、コンテンツを深掘りしていきます。この対話によって、「こういう内容も絡めて書けるな」という気づきが生まれ、コンテンツの幅が広がります。また、初期調査として、構成の組み方や必要な技術についても情報収集を行っています。 2. アウトライン作成 書く内容が決まった時に、どういう流れで文章を書いていくかをClaudeに提案してもらいます。人間が一から考えるのではなく、AIに出力してもらうことで、執筆前に「この観点が必要だった」といった見落としを未然に防ぐことができています。この段階でのClaudeの支援はとても優秀です。 3. 検証段階 公式リファレンスの調査や参考文献、技術ブログなどの情報をリストとしてまとめてもらい、検証時に役立てています。またClaudeだけでなく、GitHub Copilotなどを使ってコーディング支援も受けています。自分で書いたコードに適切なコメントを追加してもらったり、解析コメントだけを出力してもらったりといった活用をしています。 4. 執筆段階 下書きをまるごと書いてもらうことはあまりしませんが、部分的なコラムなどAIに依頼しても問題ない部分を切り分けて書いてもらっています。また、私がよく使うのは、とりあえず書いた内容の誤字脱字の修正や文体の統一です。気分によって表現方法が異なってしまうことがよくあるので、そういった部分の修正を主にClaudeにお願いしています。さらに、ブログ内に登場する図の作成にもClaudeを活用しています。 5. 構成品質チェック 別ブログの評価やファクトチェック、技術ブログとしての質、トレンド性やSEO観点での優位性などをAIに判定してもらっています。つまり、私のブログを最初に読むのはAIだと言っても過言ではありません。この「生成AIを第一読者にする」というアプローチについては、「 【実践解説】技術ブログ品質チェック術|Gemini Deep Researchで5分検証 」で詳しく書いているので、ぜひ見てください。 2025-07-07 【実践解説】技術ブログ品質チェック術|Gemini Deep Researchで5分検証 このサムネイル、少し胡散臭いセミナーっぽくて、個人的には気に入っています。 比較で見る変化 「比較で見る変化」と題していますが、これは皆さんの目で実際に確認していただければと思います。2022年、2023年、2024年、そして2025年に書いたブログから、当時の私が力を入れて書いたものをまとめていますので、ぜひ読んでいただければと思います。 2022:Google Apps Script 簡易API編 初心者向け 2023:YouTube APIを使って自動で自分の動画の分析情報を収集する【GAS】 2024:プロジェクト開発手法を解説:ウォーターフォール、アジャイル、MVPの特徴 2025:Azure SWA×Next.js認証API統合を実践解説【DevContainer〜本番まで】 具体的な数字については、投稿頻度にはコンテンツ量などの要素があり純粋な比較は難しいものの、変化は明らかです。ブログを見ていただくとわかりますが、2025年にAIを活用して書いているブログは内容がかなり充実しています。また、サムネイルもおしゃれになっています(これが使用ツールの変化か私のデザイン力向上かは置いておいて)。 ブログの構成も大きく変わりました。以前は章立てがざっくりしていたり情報が不足している部分がありましたが、最近は品質チェックを導入しているため、章立てが細かく分かれています。また、背景説明から問題提起、解決編へとスムーズに導く自然な文章構成になっています。 面白い例として、完全にAIに執筆してもらったブログも一件あります。私がシリーズ3本を1週間(合計約24時間)かけて書いたブログを入力として使い、文体を抽出したプロンプトを用意してAIに投げたところ、執筆時間わずか2分という驚異的なスピードでブログが完成しました。 体感の投稿頻度や質は上がっていますが、月ごとの比較では信頼性の高いデータを示すのが難しいです。PV(ページビュー)についても、以前は10人程度しか見られないブログもありましたが、トレンド性を意識することで大幅に改善しました。月間比較では10倍や100倍になったケースもあります(過去の私のブログが単に良くなかったという可能性が大です)。 品質の低いブログを公開前に止められる取り組みが効果を発揮しているのでしょう。思えば、昔の自分は全ての事柄をブログにアウトプットしていたので、狂気的ですよね。 現在の最適化された執筆環境 現在ではClaudeを活用することによって、ブログの作業を分割しても問題なくなりました。これはなぜかと言いますと、まず文体の調整や誤字脱字はすべてAIによって修正してもらえるので、どのタイミングで執筆をしたとしても一貫性を保てるようになりました。 そして、新しいフェーズとして、AIによる品質向上チェックを追加しています。また、執筆現場では、完全にきれいな文章を書くというよりも、まず文章に起こすということを意識しているので、執筆時間自体は今までと比べて大幅に短縮されています。企画・リサーチ・構成設計の部分もAIに助けてもらっているので、Claudeにアクセスできる環境さえあれば、作業を分割して進めることができるようになり、あらゆる場面で独立した作業が可能になっています。 また、Claude導入以前との大きな違いは、業務とそのアウトプットとしてブログを書いていた際の検証部分をAIに助けてもらうことで、スムーズかつ今までと比較にならないスピードでの検証が可能になりました。検証や調査も効率的に行えるようになったので、AIにできる部分は積極的に任せています。 最適化後の執筆プロセス(総時間:4-6時間) Phase 1: 企画・リサーチ(30分) Phase 2: 構成設計(30分) Phase 3: 執筆(2-3時間) Phase 4: 品質向上(1-2時間) 試験的取り組みとして、音声入力を活用してキーボードを叩かずに、言葉で発することで文章を文字起こしして、それをAIに補正してもらうような活動もしています。これをすることによって、まず指が疲れないのが最高ですね。長編のブログを書くと、すごく指が筋肉痛になるんじゃないかっていうぐらい酷使してしまうので、そういったところがなくなったというのは結構効果的ですね。これがいい感じにまとまったらブログとして出していきますので、お楽しみに。 各工程でのClaude活用(プレビュー) 各工程でのClaude活用(プレビュー)については、Claudeにどのようなプロンプトを投げかけ、具体的にどう活用しているのかをご紹介します。 企画段階での活用例 この使い方では、ブログを書く前に内容を詰めるための作業を行っています。こちらのブログは最終的に「 Claude調教術 暴走パターンを制御する3つのプロンプトテクニック 」というブログになりました。 プロンプト: プロンプトを書くのが苦手な方向けにブログを書こうと思っています。 Goal - ブログの仮タイトル - コンテンツの一覧の作成:ブログの分析者としてブログコンテンツの価値や差別化に関して、SEO観点から競合調査するための調査計画書の作成 Plan - ブログの各コンテンツを対話的に確認する - ブログのコンテンツに関する情報が足りていない場合は確認 - コンテンツからSEO的観点で追加コンテンツの提案 - ステップの終了確認:終了しない場合は、再度対話的に確認 出力例: プロンプトが苦手な方向けのブログ企画、素晴らしいアイデアですね!SEO観点からの競合調査も含めた包括的な計画を立てましょう。 仮タイトル案 「プロンプト初心者でも今日から使える!AI活用術ブログ」 ... 執筆段階での活用例(校閲と表現の統一) この使い方では、ブログの執筆中に使用しています。今もNotionの右側にはClaudeが開かれています。ここでは、校閲と表現の修正を行っています。 プロンプト: ブログのアウトラインと部分的に執筆した内容を送付します。 部分的に執筆したので、校閲と表現の修正をお願いします。 「執筆前整理」のセクションに関しては出力に含めなくてよいです。 何か懸念や疑問がありましたらチャットで簡素にまとめて質問してください。 - 添付1:ブログアウトライン - 添付2:執筆した部分的なブログ 出力例: ども!7月の追い込みが激しくて、いろんなものに追い回されている龍ちゃんです。まぁすべてを引き受けたのは自分なので自己責任ですが、調子に乗っていたなと反省しています。とはいえ、割と順調に片付いているので、余裕が出てきたからこその発言なんですけどね。 6〜7月は13本ほどブログを執筆していますね。そんなブログのお話を今回書いていこうと思います。前半は若干のポエムの可能性もあるので、流し見で見てもらえればと思います。 今回は「Claude活用で変わった技術ブログ執筆のお話」になります。それでは始めましょう。 ~~省略~~ 以下は実際の執筆中の画面です。 品質チェック段階での活用例 この使い方では、「 【実践解説】技術ブログ品質チェック術|Gemini Deep Researchで5分検証 」で解説している内容と似ています。受け取った評価をそのまま信じるわけではありません。ですが、最新リソースなどから複合的な観点での品質チェックを行ってくれます。 今回のプロンプトでは E-E-A-T とトレンド性という観点で評価を行ってもらっています。 プロンプト: 添付されたファイルから内容を把握して、技術ブログとして評価してください。 E-E-A-Tとトレンド性なども含めて評価をよろしくお願いします。 - 添付ファイル:完成したブログ 出力例: この技術ブログを分析して評価いたします。 全体的な評価 この記事はDevContainerを使用したStreamlit開発環境の構築について具体的で実用的な内容を提供しており、技術ブログとしての質は高いです。 各要素の評価 E-E-A-T(Experience, Expertise, Authoritativeness, Trustworthiness) Experience(経験): 8/10 実際の開発経験に基づいた内容 具体的な設定ファイルとコード例を豊富に提供 flake8とblackの設定競合問題など、実開発で遭遇する課題を解決 ~~~省略~~ 現在のツール使い分けと課題 現在のツール使い分けと課題について説明します。私が使用できるAIツールは、Notion AI、Gemini、Claude、そしてGitHub Copilotの4つです。 Notion AI → Claude への移行体験 これまでのツール活用としては、Notion AIとClaudeを使っていました。タイトルやメタディスクリプションはNotion AIで作成していましたが、現在はNotion AIからClaudeに完全に移行しています。 Notion AIの活用方法として、Notion上で執筆をしているため、初期の文法の誤りや日本語的な表現の誤り、文章構成などの部分で特に活用していました。そして最終的に構成した文章をClaudeにも入力して、全体的な修正を行っていました。つまり、Notion AIで部分的な修正を行いながら、最終的な調整はClaude側でやってもらうという使い分けをしていました。 Claude移行後は、技術的な正確性と構造化された対話の質が大幅に向上しました。特に技術ブログ執筆での精度が圧倒的に向上し、修正した内容をそのまま反映できるため、執筆環境においてはClaudeがとても魅力的です。 Gemini活用の現状と品質チェック手法 Geminiも使えるのですが、Geminiは「AIを第一読者にする」というブログで紹介したように活用しています。執筆段階でGeminiを使うことはほとんどなく、調査やブログの最終的な評価の部分でDeep Researchを活用しています。 執筆に関連する使い方としては、執筆後のブログコンテンツの評価やブログを書く前の調査という部分です。Geminiでできることは、Claudeでも同様のことができます。 Geminiの利点として、会社のワークスペースで契約していて単純に使い放題なのが強みです。一方で私はClaudeをProプランで契約していますが、5時間ごとに利用制限がある点が弱点です。そのため、日常的な調査はGeminiに任せ、より詳細なタスクはClaudeに任せるという切り分けを行っています。 Research機能の比較:Claude vs Gemini Deep Research ClaudeのResearch機能は2025年5月現在、日本、アメリカ、ブラジルのMax、Team、Enterpriseプランのユーザー向けにβ版として提供されています。私は「AIを第一読者にする」という手法を実践していますが、これはClaudeでも同じことをやっています。 ClaudeのResearch機能とGeminiのDeep Researchを同時に使い、両方のAIがOKと言えば概ねOKだろうと判断しています。つまり、第一査読者、第二査読者のような感じで使っています。 検索能力について、文章中で「600件検索」と記載しましたが、これは私の記憶違いの可能性があります。実際の検索件数については、使用する際の複雑さや設定によって変動するため、正確な数値比較よりも、出されたレポート結果の質が重要です。 体感的な違いとして、Geminiの方が出すレポートは非常に硬くて読みにくいです。一方、Claudeのレポートも硬さはありますが、レポート形式の指定ができるので、フォーマットを定義できる点でClaudeの自由度が高いと感じています。 各AIサービスの特徴と使い分け 各AIサービスにはそれぞれ強みと弱みがあり、得意な分野と不得意な分野があります。役割が重複する部分でも好みの差があります。 文体・表現の違い Gemini : 表現として非常に硬い文章を出力 Claude : 指定すれば柔らかい文体や特定のスタイルで表現 Notion AI : 入力ができる領域は限定的だが小さい範囲での修正の力は協力 GitHub Copilot の特化領域 GitHub Copilotはコードレビューやコード関連に特化している点が強みです。ClaudeもGeminiもコードを出力できますが、拡張機能で簡単に使えるGitHub Copilotは非常に便利です。特に設定なしでGitHubと連携できるので、GitHub上で何かサービスを使うならCopilotが優勢です。 単純に比較することは難しいですが、それぞれの得意分野を見極めながら活用していきたいと思います。今後のブログでは、Claudeで検証している内容がGeminiでもできるのかといった比較も触れていければと思います。 参考情報 Claude関連の公式リファレンス Claude Proには使用制限がありますか? | Anthropicヘルプセンター Claude Proの使用について | Anthropicヘルプセンター Claudeの最大プラン使用量について | Anthropicヘルプセンター Claude.aiでの研究の利用 | Anthropicヘルプセンター Research機能の公式発表 | Anthropic GitHub Copilot GitHub Copilot 公式ページ Google Workspace & Gemini Google Workspace 公式ページ Gemini for Google Workspace 今後の展望とシリーズ予告 今後の展望と課題 最近気になっているのは、Claudeでツール連携ができるようになった点です。これがもう少し使いやすくなれば、NotionやGitHubとも連携できるので、Claude上でアクセスするだけで様々なサービスに問い合わせができるようになるでしょう。 ただし、AIにすべてを委譲することでレート制限に達したり、課金が高額になるリスクもあるので、安全に運用できる仕組みも今後しっかりと設定する必要があります。 今後はブログの執筆だけでなく、PV数などの分析や、ブログコンテンツにさらに踏み込んだAI活用も模索していきたいと思います。当面の計画として、各プロンプトのテクニックをシリーズ形式で執筆していこうと考えています。 実際に現在取り組んでいる内容として、 Claudeでブログコンテンツからツイート(X)の投稿文を生成する検証も行っており、その結果もブログ に掲載しています。ブログ作成からSNS投稿、継続的な発信、校閲といった一連のプロセスを通して、情報発信という観点とAIの組み合わせによる新しい可能性を探っていければと思っています。 シリーズ記事の執筆予定 今後、シリーズとして執筆したブログは以下にまとめていきます。まあ、現状では一本も執筆していないので…。えっと、もしも更新が止まっていたら、X上でつついてください。 各記事で執筆する予定のコンテンツを箇条書きでまとめておきます。 第2回:品質向上編 技術的正確性の担保方法 読者体験最適化のテクニック 実際の改善事例と測定方法 第3回:構成・アウトライン編 論理的な構成設計のコツ 読者レベル別の調整方法 SEOを意識した構造化 第4回:SEO最適化編 技術系キーワード戦略 検索意図に合わせたコンテンツ設計 効果測定と改善サイクル 第5回:ビジュアル制作編 Artifacts活用の図解作成 技術概念の可視化テクニック 読者理解を深める工夫 第6回:サムネイル・デザイン編 クリック率向上のデザイン戦略 A/Bテストによる最適化 継続的な改善プロセス 読者への呼びかけ 技術ブログの執筆に取り組んでいる皆さんにとって、今回紹介したClaude活用法が少しでも参考になれば幸いです。AI技術は日々進歩しており、新しい活用法も次々と生まれています。 実際に試してみて、うまくいった方法や課題があれば、ぜひコメントやSNSで教えてください。皆さんの体験談も今後の記事に反映していきたいと思います。 次回の記事もお楽しみに!そして、更新が止まっていたら遠慮なくつついてくださいね。 ご覧いただきありがとうございます! この投稿はお役に立ちましたか? 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude×技術ブログで執筆環境が激変!次世代AI協働ワークフロー解説 first appeared on SIOS Tech. Lab .
挨拶 ども!最近はAI関連からInfrastructure as Code(IaC)などにも入門して幅広いブログを執筆している龍ちゃんです。最近はブログ執筆にAIを導入して、執筆スピードと質が上がっているような気がして楽しいですね。7月にまとめた内容は8月の初頭に45分セミナーにまとめるので、激しめに検証を進めています。 さて今回は「Stremlit」のお話になります。最近ふんわりとStremlitを書く機会が増えたので、DevContainerで開発する環境構築をまとめていこうと思います。 Stremlit開発環境をDevContainerで作成する 今回は、開発環境を使いまわす可能性を考慮してGitに環境を上げています。もし使いたい方がいれば、 リポジトリをクローン して利用してください。 ディレクトリ構成 今回作成する環境のディレクトリ構成になります。venvなどでも構築できるように .devcontainer 内でコンテナの定義をすべて収めています。リポジトリのトップからマウントすることで、コンテナ内でGit操作をすることができます。 . ├── .devcontainer │ ├── Dockerfile │ ├── compose.yml │ └── devcontainer.json ├── .env ├── .gitignore ├── README.md ├── requirements.txt ├── sample.env ├── setup.cfg └── src └── main.py Dockerfile ベースイメージは、 Microsoftが出しているPython 3.11のベースイメージ を利用しています。利点として、以下の二点があります。 Gitが標準で搭載されている vscodeユーザーがデフォルトで作成されている(非rootユーザー) コード解析・フォーマッター「flake8」「black」が標準搭載 Dockerfile内で行っている処理は、pipのアップグレードのみになります。 # Use the official Microsoft Python image (Debian Bullseye based) FROM mcr.microsoft.com/devcontainers/python:1-3.11-bullseye # Set the working directory WORKDIR /home/vscode/python # Install Python packages that are commonly used RUN pip install --upgrade pip # Keep the container running CMD ["sleep", "infinity"] compose.yml 将来的な拡張(データベース等)を考えて、composeファイルで定義しています。リポジトリのルートディレクトリからマウントすることで、仮想環境内からGitコマンドを直接実行することができます。 Streamlitでデフォルトで公開されるポート(8501)を接続しています。 services: python: build: context: . dockerfile: ./Dockerfile tty: true volumes: - type: bind source: ../ target: /home/vscode/python restart: always ports: - "8501:8501" devcontainer.json 今回作成するファイルの中で最も記述量が多いファイルになります。基本的にコピー&ペーストで大丈夫です。設定している主要項目としては以下になります。 拡張機能の追加 開発環境設定 開発用feature(Azure CLI・GitHub CLI) 開発環境設定では、pylintを無効化してflake8を有効化するように設定しています。ファイルをセーブしたタイミングでリンターとフォーマッターが実行されるように設定しています。 { "name": "Streamlit", "service": "python", "dockerComposeFile": "./compose.yml", "workspaceFolder": "/home/vscode/python", "shutdownAction": "stopCompose", "customizations": { "vscode": { "extensions": [ "ms-python.python", "ms-python.black-formatter", "ms-vscode.vscode-json", "ms-python.flake8" ], "settings": { "python.defaultInterpreterPath": "/usr/local/bin/python", "python.formatting.provider": "black", "terminal.integrated.defaultProfile.linux": "bash", "python.linting.enabled": true, "python.linting.pylintEnabled": true, "python.linting.lintOnSave": true, "python.linting.flake8Enabled": true, "": { "editor.formatOnSave": true, "editor.defaultFormatter": "ms-python.black-formatter" } } } }, "features": { "ghcr.io/devcontainers/features/azure-cli:1": {}, "ghcr.io/devcontainers/features/github-cli": {} }, "forwardPorts": [ 8501 ], "portsAttributes": { "8501": { "label": "Streamlit", "onAutoForward": "notify" } }, "postCreateCommand": "pip install -r requirements.txt", "remoteUser": "vscode", "updateRemoteUserUID": true } featureとしてAzure CLIとGitHub CLIをインストールしています。これは将来的にデプロイ先をAzure Web Apps on Containerでデプロイすることを考慮して設定しています。 フォーマット&リンター設定 前段の設定のみで開発を進めることができますが、一転問題があります。flake8とblackのデフォルトの設定が競合してしまい、問題が発生します。flake8かblackのどちらかに設定を合わせる必要があります。 setup.cfg ファイルを作成して、以下の内容をコピー&ペーストすることで設定することが可能です。 [flake8] max-line-length = 88 extend-ignore = E203, W503, E501 exclude = .git, __pycache__, .venv, venv, .env, env Stremlitのデモ ここまでで開発環境は整備することができたので、Stremlitで簡易的なページを作成を進めていきます。 まずは、Stremlitの機能をインストールをしましょう。 # stremlitのインストール pip install streamlit # requirements.txtにインストールしたファイルの設定 pip freeze > requirements.txt src > main.py を設定して以下のファイルをコピー&ペーストをしてください。 import streamlit as st import pandas as pd import numpy as np st.set_page_config(layout="wide") st.title("🚀 Streamlitの素晴らしい利点") st.write( "Streamlitを使えば、データサイエンスのプロジェクトを瞬く間にインタラクティブなWebアプリに変えることができます。" "もう複雑なWeb開発の知識は必要ありません!" ) st.subheader("💡 利点1: 圧倒的な手軽さ") st.write( "Pythonの知識だけで、データスクリプトから直接Webアプリを作成できます。HTML、CSS、JavaScriptなどの" "フロントエンドの知識は一切不要です。これにより、開発時間を大幅に短縮できます。" ) st.code( """ import streamlit as st st.title("こんにちは、Streamlit!") st.write("これはたった数行のコードです。") """ ) st.subheader("⚡ 利点2: 迅速なプロトタイピング") st.write( "コードを変更するたびに、アプリがリアルタイムで更新されます。これにより、アイデアをすぐに形にし、" "フィードバックを得ながら反復的に開発を進めることができます。まるでライブコーディングをしているようです!" ) st.info( "💡 ヒント: このページを保存して、Streamlitを実行したままコードを編集してみてください。" ) st.subheader("📊 利点3: 美しいデータ可視化が簡単に") st.write( "Matplotlib, Plotly, Altairなどの既存のPython可視化ライブラリとシームレスに統合できます。数行のコードで" "インタラクティブなグラフやダッシュボードを作成できます。" ) # サンプルグラフの表示 chart_data = pd.DataFrame(np.random.randn(20, 3), columns=["a", "b", "c"]) st.line_chart(chart_data) st.bar_chart(chart_data) st.subheader("🔄 利点4: インタラクティブなウィジェット") st.write( "スライダー、ボタン、テキスト入力など、多様なウィジェットを簡単に組み込むことができます。" "これにより、ユーザーがデータと対話できる動的なアプリケーションを作成できます。" ) # インタラクティブなデモ value = st.slider("スライダーを動かしてみてください", 0, 100, 50) st.write(f"現在の値: {value}") button_clicked = st.button("ボタンを押してみてください") if button_clicked: st.success("ボタンが押されました!") user_text = st.text_input("ここに何か入力してください", "Streamlitは最高!") st.write(f"あなたが入力した内容: {user_text}") st.subheader("☁ 利点5: デプロイのしやすさ") st.write( "Streamlit Community Cloudを使えば、数クリックでアプリをWebに公開できます。また、Dockerなどの" "コンテナ技術と組み合わせることで、より柔軟なデプロイも可能です。" ) st.video("https://www.youtube.com/watch?v=NtLCVE9hwb8") # Streamlitの紹介動画(例) st.write("---") st.markdown( "### まとめ\n" "Streamlitは、データサイエンティストやアナリストがアイデアを迅速に具現化し、" "それをインタラクティブな形で共有するための強力なツールです。" "ぜひご自身のプロジェクトで試してみてください!" ) st.balloons() ファイルを作成したら、以下のコマンドで起動することができます。 streamlit run src/main.py デフォルトで http://0.0.0.0:8501 が立ち上がって真っ白な画面が立ち上がってもあせらなくて大丈夫です。 http://localhost:8501 にアクセスしてみてください。以下の画面が表示されれば成功です。 まとめ 今回は、StreamlitをDevContainerで開発する環境構築について詳しく見てきました。DevContainerを使うことで、チーム内での開発環境統一や、プロジェクトの引き継ぎがスムーズになりますね。 特に今回のポイントとしては、MicrosoftのPython 3.11ベースイメージを使うことで、Gitやコード解析ツールが標準搭載されている点が大きなメリットでした。また、flake8とblackの設定競合問題も、setup.cfgファイルで解決できることがわかりました。 Streamlitは本当に手軽にデータアプリケーションを作成できる素晴らしいツールです。今回構築した環境なら、コードを変更するたびにリアルタイムで結果を確認できるので、開発効率が格段に向上します。 皆さんも、ぜひこの環境でStreamlitアプリケーション開発にチャレンジしてみてください!GitHubリポジトリも公開しているので、クローンして即座に開発を始められます。 次回は、このStreamlit環境をAzure Web Apps on Containerでデプロイする方法について解説予定です。お楽しみに! こちらのブログ「 Infrastructure as Code実践:Azure SWA×Bicep×GitHub Actions 」と同様の手順でBicepで環境作成からAzureへのデプロイまで目指していきます。 ご覧いただきありがとうございます! この投稿はお役に立ちましたか? 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post DevContainerでStreamlit開発を始める方法:Docker+VSCode first appeared on SIOS Tech. Lab .