サむオステクノロゞヌTech.Labのブログ - TECH PLAY

TECH PLAY

サむオステクノロゞヌTech.Lab

サむオステクノロゞヌTech.Lab の技術ブログ

å…š672ä»¶

こんな方ぞ特におすすめ 新卒゚ンゞニアになった方 本栌的な開発環境を構築したい方 抂芁 こんにちは。サむオステクノロゞヌのはらちゃんです新卒ずしお4月に入瀟し、今回初めおのブログ執筆です。 VS CodeはWSL䞊で起動すべきだずいう3぀の理由ずその手順をお䌝えしたす。 WSLずGit Bashの違いに぀いお気になる方は、 こちらのブログ をご芧ください。   わたしの悩み Windows PCで開発環境を敎え、いよいよコヌディングを始めようずしたずき、先茩゚ンゞニアからこう蚀われたした。   「VS CodeはWSL䞊で起動するようにね」   Windows䞊でアむコンをクリックすれば快適に動くのに、なぜわざわざ黒い画面タヌミナルから起動する必芁があるんだろう  私も最初はそう思い、少し戞惑いたした。 しかし、この「WSL䞊でVS Codeを起動する」ずいう䞀手間には、将来のあなたの開発効率を劇的に向䞊させる、明確で重芁な理由が3぀あったのです。 今回は、その理由ず具䜓的な手順を分かりやすく解説したす。   3぀の理由 理由1Linuxの圧倒的なパフォヌマンスを掻かせる   「   npm install がやたら遅い 」「 git status  の衚瀺に時間がかかる 」 もしあなたがWindows䞊で盎接これらのコマンドを実行しおいるなら、その原因は ファむルシステムの盞性の悪さ かもしれたせん。 Windowsが䜿っおいる「NTFS」ずいうファむルシステムは、Linux向けのツヌル矀ずの盞性が良くありたせん。䞀方、WSL内のLinuxが䜿っおいるファむルシステムext4は、これらのツヌルが最高のパフォヌマンスを発揮できるよう最適化されおいたす。 VS CodeをWSL䞊で起動するこずで、ファむル操䜜がすべおLinux内で完結するため、 驚くほどコマンドの実行が速く なりたす。この速床差は、日々の開発業務においお倧きなストレス軜枛に繋がりたす。   理由2ツヌルの「互換性」問題を根本から回避できる   Web開発で䜿われるツヌルの倚くは、元々Linux環境で䜿われるこずを前提に䜜られおいたす。そのため、Windows環境でそのたた䜿おうずするず、様々な互換性の問題に盎面するこずがありたす。 パスの蚘法: Windows C:\Users\Taro ずLinux /home/taro  のようなパスの違い。 シェルスクリプト: OSによるコマンドの違いで、配垃されたスクリプトが動かない。 Docker: Linuxカヌネルの機胜に䟝存しおいるため、WSL2䞊が最もスムヌズ。 VS CodeをWSL䞊で起動すれば、あなたの開発環境はLinuxそのものになりたす。これにより、厄介な互換性の問題を未然に防ぎ、ツヌルの導入や実行で悩む時間を倧幅に削枛できたす。   理由3チヌム開発で「環境差異」に悩たなくなる 「自分のPCだず、なぜか動かない 」 チヌム開発で最も避けたいのが、この 環境差異によるトラブル です。チヌムにmacOSやLinuxを䜿っおいるメンバヌがいるず、OSの違いが原因で、あなただけが゚ラヌに遭遇するケヌスは少なくありたせん。   簡単WSLから起動する手順 前提条件 WSL2 Ubuntuなどがむンストヌルされおいるこず。 Windowsに Visual Studio Code 本䜓がむンストヌルされおいるこず。   ステップ1拡匵機胜「Remote – WSL」をむンストヌルする たず、VS CodeずWSLを連携させるための公匏拡匵機胜をむンストヌルしたす。   Windows䞊で普通にVS Codeを起動したす。   アプリのアむコンかスタヌトメニュヌで怜玢しおください   巊偎のアクティビティバヌにある四角いアむコン拡匵機胜をクリックしたす。   画面巊のメニュヌバヌから拡匵機胜䞊から6぀目を遞択できたす   怜玢バヌに「 Remote – WSL 」ず入力したす。   衚瀺された拡匵機胜Microsoft補の「むンストヌル」ボタンをクリックしたす。   ステップ2WSLタヌミナルから「code .」で起動する 次に、WSLのタヌミナルからVSCodeを起動したす。 Windows TerminalやUbuntuのアプリなどから、WSLのタヌミナルを起動したす。   画像はUbuntuです。ご自身の環境に合わせおください   cd  コマンドを䜿っお、開発プロゞェクトのあるディレクトリに移動したす。     # 䟋ホヌムディレクトリの 'projects/my-app' に移動     cd ~/projects/my-app     そのディレクトリで、以䞋のコマンドを実行したす。         code .     code .  は、「 今いるディレクトリカレントディレクトリをVS Codeで開いお 」ずいう意味のコマンドです。 初めお実行する際は、WSL偎にVS Codeのサヌバヌが自動でむンストヌルされるため、少し時間がかかりたす。2回目以降はすぐに起動したす。 起動したVS Codeの巊䞋が緑色になり、「 WSL: Ubuntu 」のように衚瀺されおいれば成功ですこれであなたのVS Codeは、WSL環境に接続された状態で動いおいたす。   たずめWindows × WSL × VS Codeは「最匷の組み合わせ」 今回ご玹介した方法は、Windowsの快適なUIず操䜜性を享受し぀぀、Linuxの匷力で安定した開発環境の恩恵も受けられる、たさに「いいずこ取り」のテクニックです。 最初は少し䞍思議に感じるかもしれたせんが、この方法を䞀床マスタヌすれば、今埌のあなたの゚ンゞニアキャリアにおいお、蚈り知れないメリットをもたらしおくれるはずです。 Windowsでの開発に、もはや劥協は必芁ありたせん。今日からあなたも「 code . 」をWSLで叩いお、快適な開発ラむフをスタヌトさせたしょう     ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post VS Codeの䜿い方WSL連携で開発効率を䞊げる方法 first appeared on SIOS Tech. Lab .
[sng_toc_insert]   タヌゲット プログラミング孊習者 Windowsでこれから開発を行う開発者 フロント゚ンドからバック゚ンドぞ挑戊し始めた゚ンゞニア   抂芁 こんにちは。サむオステクノロゞヌのはらちゃんです連続で2本目のブログ執筆です。 WSLずGit Bash、2぀の違いをメリットやデメリットを螏たえお解説したす。 WSLでVS Codeの開発効率を䞊げるこずが気になる方は、 こちらのブログ をご芧ください。   はじめに  Windowsで開発を始めるず、必ず出䌚う2぀の黒い画面がありたす。 それがWSLずGit Bashです。 どちらもLinux颚のコマンドが䜿えお䞀芋䌌おいたすが、その正䜓ず埗意なこずは党く異なりたす。 間違ったツヌルを遞ぶず、埌々「やりたいこずができない 」ず遠回りしおしたうこずも。 簡単に蚀うず、WSLは「Windows䞊で本物のLinuxを動かす」のに察し、Git Bashは「Windows䞊でLinuxのコマンドを擬䌌的に再珟する」ものです。 この蚘事では、䞡者の根本的な違いからメリット・デメリットたでを培底比范し、あなたがどちらを遞ぶべきかの明確な指針を解説したす。   根本的な違い  ãŸãšã€äž¡è€…の最も重芁な違いを衚で芋おみたしょう。   WSL (Windows Subsystem for Linux) Git Bash OS環境 完党なLinuxカヌネルが動䜜する仮想環境 Windows䞊で動䜜するBash゚ミュレヌタヌ できるこず Linuxでできるこずはほが党お可胜 ・apt等のパッケヌゞ管理 ・サヌバヌ゜フトの起動など Git操䜜ず基本的なUNIXコマンドが䞭心 パフォヌマンス Linuxファむルシステム内は高速 Windowsずのファむルやり取りは若干遅い Windowsファむルシステム䞊で動䜜 そのため、ファむルアクセスは高速 リ゜ヌス消費 比范的倧きいメモリ、CPU 軜量 WSLの特城   メリット 完党なLinux環境  apt や yum ずいったパッケヌゞマネヌゞャヌを䜿い、膚倧なLinuxのツヌルやアプリケヌションを自由にむンストヌルできたす。WebサヌバヌApache, NginxやデヌタベヌスMySQL, PostgreSQLなども動䜜させられたす。 高い互換性  Linux向けのアプリケヌションや開発ツヌルDockerなどをそのたた利甚でき、本番環境がLinuxの堎合に開発環境を限りなく近づけるこずができたす。 パフォヌマンス  Linuxファむルシステム内の凊理は非垞に高速です。コンパむルや倧芏暡なファむルの凊理などでその真䟡を発揮したす。   デメリット セットアップがやや耇雑  Git Bashに比べるず、有効化やディストリビュヌションのむンストヌルなど、初期蚭定に手間がかかりたす。 リ゜ヌス消費量が倚い  仮想マシンに近い圢で動䜜するため、メモリやCPUの消費量はGit Bashよりも倚くなりたす。 Windowsファむルずの連携  WSL内のLinuxからWindowsのファむル /mnt/c/ などにアクセスするず、パフォヌマンスが䜎䞋する傟向がありたす。   Git Bashの特城   メリット 手軜さ  Git for Windowsをむンストヌルするだけで利甚でき、非垞に軜量です。 Windowsずの芪和性  Windowsのファむルシステム䞊で盎接動䜜するため、ファむルのパス指定などが盎感的で、パフォヌマンスの䜎䞋もありたせん。 Gitに最適化  もずもずGitを䜿うために䜜られおいるため、Gitの操䜜に必芁なコマンドは䞀通り揃っおおり、シンプルにバヌゞョン管理をしたい堎合には十分です。   デメリット 機胜の制限  あくたで゚ミュレヌタヌなので、䜿えるUNIXコマンドは限定的です。 apt のようなパッケヌゞマネヌゞャヌは䜿えず、新しいツヌルを自由に远加するこずはできたせん。 本栌的な開発には䞍向き  Linuxの豊富な開発ツヌルやラむブラリを利甚するこずができないため、耇雑なWebアプリケヌション開発などには向いおいたせん。 シェルスクリプトの互換性  䞀郚の耇雑なシェルスクリプトは、完党なLinux環境ず挙動が異なる堎合がありたす。   【ハンズオン】䜿っおみよう 理屈がわかったずころで、実際にツヌルをむンストヌルしおみたしょう。どちらも数ステップで簡単に導入できたす。   WSLの導入方法  çŸåœšã®Windowsでは、WSLの導入が驚くほど簡単になっおいたす。管理者暩限のタヌミナルから、たった䞀぀のコマンドを実行するだけです。   管理者ずしおタヌミナルを開く スタヌトボタンを右クリックし、「タヌミナル (管理者)」たたは「Windows PowerShell (管理者)」を遞択したす。 「このアプリがデバむスに倉曎を加えるこずを蚱可したすか」ず衚瀺されたら、「はい」をクリックしたす。     むンストヌルコマンドを実行 開いたタヌミナルに、以䞋のコマンドをコピヌペヌストしお、Enterキヌを抌したす。 wsl --install このコマンドが、WSLを有効化し、デフォルトのLinuxディストリビュヌションである「Ubuntu」のダりンロヌドずむンストヌルたで、すべお自動で行っおくれたす。   PCを再起動 むンストヌルが完了したら、PCを再起動するように促されるので、再起動したす。 初期蚭定を行う 再起動埌、Ubuntuのタヌミナルが自動で起動し、初期蚭定が始たりたす。 Linux環境で䜿うナヌザヌ名ずパスワヌドを蚭定するように求められるので、入力しおください。 このパスワヌドは、 sudo コマンドなどで䜿う重芁なものなので、忘れないようにしたしょう     Git Bashの導入方法  Git Bashは、「Git for Windows」ずいうパッケヌゞに含たれおいたす。以䞋の手順でむンストヌルしたしょう。   公匏サむトにアクセス たず、 Git for Windowsの公匏サむト にアクセスしたす。   むンストヌラヌをダりンロヌド トップペヌゞにある「Download」ボタンをクリックしお、むンストヌラヌをダりンロヌドしたす。   むンストヌラヌを実行 ダりンロヌドしたファむルを実行したす。基本的に、すべおデフォルト蚭定のたた「Next」を抌し続けお問題ありたせん。途䞭で初期ブランチ名を main に倉曎するかどうかなど、いく぀か質問されたすが、よく分からなければそのたたで倧䞈倫です。 公匏サむト も参照するず理解が深たるず思いたす。   むンストヌル完了 むンストヌルが終わったら、デスクトップやスタヌトメニュヌに「Git Bash」のアむコンが远加されたす。これをクリックすれば、い぀でもGit Bashを起動できたす。     結論  çµå±€ã€ã©ã¡ã‚‰ãŒè‰¯ã„ずいう話ではなく、あなたの目的に合わせお遞ぶのが最適です。   Git Bashがおすすめな方 䞻な目的がGitのバヌゞョン管理である。 Windowsネむティブな開発が䞭心で、ちょっずしたUNIXコマンド ls , rm , grep などを䜿いたい。 ずにかく手軜に、玠早く環境を構築したい。   WSLがおすすめな方 Web開発など、本番環境がLinuxサヌバヌである。 Dockerコンテナを䜿いたい。 Linuxの豊富なコマンドやツヌル、プログラミング蚀語環境をフル掻甚したい。 本栌的なクロスプラットフォヌム開発を行いたい。   たずめ 今回ご玹介したのは、本栌的な開発ならWSL、Gitの手軜さを求めるならGit Bashずいう、それぞれのツヌルの明確な圹割分担です。 最近の開発トレンドでは、Dockerの利甚やバック゚ンド開発でLinux環境が求められるこずが倚いため、本栌的な開発を行うならWSLの利甚が匷く掚奚されたす。 䞀方で、Gitの操䜜や簡単なコマンド実行が目的なら、Git Bashの手軜さは䟝然ずしお倧きな魅力です。 この蚘事を参考に、あなたの目的に合った最高の盞棒を遞んで、快適な開発ラむフをスタヌトさせたしょう         ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post 開発環境の遞び方WSLずGit Bashの根本的な違いを解説 first appeared on SIOS Tech. Lab .
はじめに こんにちはサむオステクノロゞヌのぺんぎんです! 新卒1幎目、初めおのブログ執筆です。よろしくお願いいたしたす 私がlinuxの暩限呚りに振り回された䜓隓蚘を執筆したす。 今回はDockerコマンド実行時にsudo暩限を぀けないず実行できない゚ラヌが発生したため、その解決方法を共有したす。 前提条件 Ubuntu 24.04.1 LTS(WSL2䞊で利甚) Docker version 28.1.1 抂芁 ずある日、Dockerやubuntuの環境構築を終え、コンテナの勉匷のためdocker-compose.yml、Dockerfileを䜜成し、docker compose upを実行しようず思い、コマンドを打ちたした。するず 䞋蚘゚ラヌが発生したした failed to solve: ubuntu:16.04: failed to resolve source metadata for docker.io/library/ubuntu:16.04: error getting credentials - err: exit status 1, out: `GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets was not provided by any .service files` ちなみに、この゚ラヌはsudoを付けおコマンドを実行するず起きたせんでした。 解決方法 このコマンドを打぀こずで解決したした sudo apt install gnome-keyring 解決たでの経緯 sudoを぀けないず実行できないず蚀うこずはたず暩限呚りを疑いたす。ずりあえずGemini君に「 sudo を぀けないず docker compose up が実行できない理由はなに 」ず聞いおみたした。 ↓Geminiからの回答 『はい、sudo を぀けないず docker compose up が実行できない理由ですね。これは、Linuxの暩限管理ずDockerの仕組みが関係しおいたす。 䟋えるなら、あなたは特別な料理クラブdockerグルヌプのメンバヌになったはずなのに、そのメンバヌカヌドグルヌプ暩限が、ただクラブの入口珟圚のログむンセッションで有効になっおいないか、あるいは入口そのものDockerデヌモン゜ケットに䜕か問題がある、ずいう状況です。』 どうやらdockerグルヌプなるものがあり、このグルヌプに远加されたナヌザヌはroot暩限がなくずもdockerコマンドを実行できるようになるらしい  早速远加しおみたした。 # dockerグルヌプにナヌザヌを远加 sudo usermod -aG docker $USER # dockerグルヌプのナヌザヌ確認 grep '^docker:' /etc/group # 出力 docker:x:989:䞀般ナヌザヌ名 実行埌PCの再起動を行いdockerグルヌプぞのナヌザヌの远加を反映さたした。 しかし、このアプロヌチでは解決したせんでした。 暩限の問題ではなかったみたいです。 再床Geminiに盞談したした。 『これは .docker ディレクトリの暩限の問題ではなく、 Dockerが認蚌情報を扱うための内郚的な仕組みCredential Helper 、特に secretservice ず呌ばれる郚分に問題がある可胜性が高いです。』 内郚的な問題ずいう返答だけ垰っおきお解決の糞口があたりにもなかったため、ここで先茩に盞談をしたした。 結果ずしお先茩に教えおいただいた先ほどのgnome-keyringをむンストヌルするコマンドで解決したのですがなぜ解決したのでしょうか自分なりに考察をしおみたした。 Gnome-keyring(グノヌムキヌリング)ずは キヌリングツヌルずは「パスフレヌズで暗号化されたSSH秘密鍵の、パスフレヌズ」や「ChromeやFirefoxなどのブラりザが保管するWebサむトのパスワヌド」など様々な認蚌情報を暗号化しお保管するツヌルです。 Gnome KeyeingはキヌリングツヌルでありGnomeプロゞェクトによりで開発されたした。Ubuntuではデスクトップ環境ずしおGnomeプロゞェクトで開発されたデスクトップ環境であるGnomeを暙準採甚しおいるため今回の堎合はキヌリングずしおGnome-keyringを採甚したした。 Dockerはプラむベヌトリポゞトリのむメヌゞの保管や組織アカりントやチヌム機胜の利甚などで認蚌を必芁ずしおおり、docker loginを行うこずでDocker Engineがナヌザヌの認蚌情報をホストマシンのキヌリングツヌルに保存したす。その認蚌資栌の管理にGnomeを暙準採甚しおいるUbuntuなどではGnome-keyringを利甚する。 しかし、WSLの「Ubuntu」には最䜎限のパッケヌゞのみむンストヌルされおおり、Gnome-keyringは元から入っおいない堎合も倚くありたす。そのため私の環境にはGnome-keyringが入っおいたせんでした。 そしお、代わりのキヌリングツヌルが存圚しおおらず䞀般ナヌザヌでコマンドを実行しようずしおいた私の環境ではsudoを付けないずコマンドの実行ができなかったず考えたす。 感想 この゚ラヌに぀いおの蚘事はほずんど存圚しおおらず、情報が少なかったためAIに聞いおも解決の糞口が぀かめたせんでした。 AIに頌っお解決方法を探っおいたしたが、AIだけでなくきちんずネットで蚘事を調べお有甚な蚘事を探しだすこずの難しさず倧切さを改めお実感したした。 今たで以䞊に怜玢力を぀けるため゚ラヌに向き合っおいこうず思いたした。 参考文献 https://qiita.com/onokatio/items/9ca0305e35243cca6119 https://docs.docker.jp/engine/reference/commandline/login.html ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post dockerコマンドでsudoを぀けずに実行する方法 first appeared on SIOS Tech. Lab .
こんにちはサむオステクノロゞヌの貝野です。 今回は、シングルサむンオンなどのアクセス管理ができる゜フトりェア keycloak をむンストヌルするにあたり、詊行錯誀したずころがありたしたのでその内容を共有したいず思いたす。 環境構成 今回は、䞋蚘の構成で keycloak の構築を行いたした。 OSRHEL9 (AWS 侊) keycloak のバヌゞョン2.6.32 Java のバヌゞョンOpenJDK21 たずは keycloak をダりンロヌド keycloak のドキュメント を参考に、むンストヌルを進めおいきたす。 keycloak の動䜜には Java が必芁ずなるため、事前に Java 関連パッケヌゞ (openjdk および openjdk-devel) をむンストヌルしおおきたす。 https://www.keycloak.org/downloads から keycloak-26.3.2.tar.gz をダりンロヌドしたす。 ダりンロヌドしたパッケヌゞを、任意のディレクトリ配䞋に展開したす。 # tar -xvf keycloak-26.3.2.tar.gz -C そのたた起動するず  ダりンロヌドが終わったので、ひずたず keycloak を起動しおみたす。 ドキュメント の手順に沿っお、次は bin/kc.sh start-dev を実行したす。 起動に成功するず、コン゜ヌルに Keycloak 26.3.2 on JVM (powered by Quarkus 3.20.2) started in … (以䞋省略) ず衚瀺されたす。(出力内容の䞋郚を参照) Updating the configuration and installing your custom providers, if any. Please wait. 2025-07-31 04:49:28,487 INFO [io.quarkus.deployment.QuarkusAugmentor] (main) Quarkus augmentation completed in 17015ms Running the server in development mode. DO NOT use this configuration in production. 2025-07-31 04:49:40,369 INFO [org.keycloak.quarkus.runtime.storage.database.liquibase.QuarkusJpaUpdaterProvider] (main) Initializing database schema. Using changelog META-INF/jpa-changelog-master.xml 2025-07-31 04:49:48,517 INFO [org.keycloak.spi.infinispan.impl.embedded.JGroupsConfigurator] (main) JGroups JDBC_PING discovery enabled. 2025-07-31 04:49:48,939 INFO [org.infinispan.CONTAINER] (main) ISPN000556: Starting user marshaller 'org.infinispan.commons.marshall.ImmutableProtoStreamMarshaller' 2025-07-31 04:49:49,557 INFO [org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory] (main) Node name: node_221352, Site name: null 2025-07-31 04:49:50,035 INFO [org.keycloak.services] (main) KC-SERVICES0050: Initializing master realm 2025-07-31 04:49:54,460 INFO [io.quarkus] (main) Keycloak 26.3.2 on JVM (powered by Quarkus 3.20.2) started in 25.736s. Listening on: http://0.0.0.0:8080 2025-07-31 04:49:54,461 INFO [io.quarkus] (main) Profile dev activated. 2025-07-31 04:49:54,461 INFO [io.quarkus] (main) Installed features: [agroal, cdi, hibernate-orm, jdbc-h2, keycloak, narayana-jta, opentelemetry, reactive-routes, rest, rest-jackson, smallrye-context-propagation, vertx] ドキュメントの手順では、http://localhost:8080/ にアクセスしお管理者アカりントのナヌザ名ずパスワヌドを䜜成するフォヌムに移動するようですが、私の環境では GUI 環境がないため、クラむアント端末から http://AWS むンスタンスのプラむベヌト IP:8080/ でアクセスしたずころ、䞋蚘の画面が衚瀺されたした。 “Local access required” ずいうこずなので、ロヌカル環境でのアクセスが必芁ずいうこずですが GUI 環境がないため、画面の内容に蚘茉の use a bootstrap-admin command を実行しおみるこずにしたす。 bootstrap-admin コマンドで管理者アカりントを䜜成 䞋蚘のドキュメントに、bootstrap-admin コマンドで管理者アカりントを䜜成する手順があったので、そちらを参考に管理者アカりントを䜜成しおみたす。 https://www.keycloak.org/server/bootstrap-admin-recovery 䞀時的な管理者アカりントの䜜成方法も含め、いく぀かの実行䟋が蚘茉されおいたすが、プロンプトにおナヌザ・パスワヌドを入力する bin/kc.sh bootstrap-admin user コマンドを実行したす。 䞋蚘のプロンプトにそれぞれ入力したす。 Enter username管理者のナヌザ名 Enter password管理者のパスワヌド Enter password again管理者のパスワヌド (再入力) # bin/kc.sh bootstrap-admin user Changes detected in configuration. Updating the server image. Updating the configuration and installing your custom providers, if any. Please wait. 2025-07-31 19:39:29,011 INFO [io.quarkus.deployment.QuarkusAugmentor] (main) Quarkus augmentation completed in 17397ms Server configuration updated and persisted. Run the following command to review the configuration: kc.sh show-config Next time you run the server, just run: kc.sh bootstrap-admin user --optimized Enter username [temp-admin]:admin Enter password: Enter password again: 2025-07-31 04:51:27,697 INFO [org.keycloak.quarkus.runtime.storage.infinispan.CacheManagerFactory] (main) Starting Infinispan embedded cache manager 2025-07-31 04:51:27,707 INFO [org.keycloak.quarkus.runtime.storage.infinispan.CacheManagerFactory] (main) JGroups JDBC_PING discovery enabled. 2025-07-31 04:51:28,701 INFO [org.keycloak.quarkus.runtime.storage.infinispan.CacheManagerFactory] (main) JGroups Encryption enabled (mTLS). 2025-07-31 04:51:28,938 INFO [org.infinispan.CONTAINER] (main) Virtual threads support enabled 2025-07-31 04:51:29,244 INFO [org.keycloak.infinispan.module.certificates.CertificateReloadManager] (main) Starting JGroups certificate reload manager 2025-07-31 04:51:29,416 INFO [org.infinispan.CONTAINER] (main) ISPN000556: Starting user marshaller 'org.infinispan.commons.marshall.ImmutableProtoStreamMarshaller' 2025-07-31 04:51:29,784 INFO [org.infinispan.CLUSTER] (main) ISPN000078: Starting JGroups channel `ISPN` with stack `jdbc-ping` 2025-07-31 04:51:29,787 INFO [org.jgroups.JChannel] (main) local_addr: 6c4c0bdf-a3da-4e8e-9d54-38fb7c243e37, name: ip-172-10-10-10-28803 2025-07-31 04:51:29,805 INFO [org.jgroups.protocols.FD_SOCK2] (main) server listening on *:57800 2025-07-31 04:51:29,819 INFO [org.jgroups.protocols.pbcast.GMS] (main) ip-172-10-10-10-28803: no members discovered after 7 ms: creating cluster as coordinator 2025-07-31 04:51:29,865 INFO [org.infinispan.CLUSTER] (main) ISPN000094: Received new cluster view for channel ISPN: [ip-172-10-10-10-28803|0] (1) [ip-172-10-10-10-28803] 2025-07-31 04:51:29,869 INFO [org.keycloak.infinispan.module.certificates.CertificateReloadManager] (main) Reloading JGroups Certificate 2025-07-31 04:51:29,985 INFO [org.infinispan.CLUSTER] (main) ISPN000079: Channel `ISPN` local address is `ip-172-10-10-10-28803`, physical addresses are `[172.10.10.10:7800]` 2025-07-31 04:51:30,719 INFO [org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory] (main) Node name: ip-172-10-10-10-28803, Site name: null 2025-07-31 04:51:32,655 INFO [org.keycloak.services] (main) KC-SERVICES0077: Created temporary admin user with username admin 2025-07-31 04:51:32,674 INFO [io.quarkus] (main) Keycloak 26.3.2 on JVM (powered by Quarkus 3.20.1) started in 63.431s. Listening on: 2025-07-31 04:51:32,674 INFO [io.quarkus] (main) Profile nonserver activated. 2025-07-31 04:51:32,675 INFO [io.quarkus] (main) Installed features: [agroal, cdi, hibernate-orm, jdbc-h2, keycloak, narayana-jta, opentelemetry, reactive-routes, rest, rest-jackson, smallrye-context-propagation, vertx] 2025-07-31 04:51:32,713 INFO [org.infinispan.CLUSTER] (main) ISPN000080: Disconnecting JGroups channel `ISPN` 2025-07-31 04:51:32,725 INFO [org.keycloak.infinispan.module.certificates.CertificateReloadManager] (main) Stopping JGroups certificate reload manager 2025-07-31 04:51:32,729 INFO [com.arjuna.ats.jbossatx] (main) ARJUNA032014: Stopping transaction recovery manager 2025-07-31 04:51:32,779 INFO [io.quarkus] (main) Keycloak stopped in 0.097s # これで、管理者のナヌザ・パスワヌドが蚭定されたした。 再床 bin/kc.sh start-dev を実行しおみるず、今床はログむン画面が衚瀺されたした。 先ほど蚭定したナヌザ名・パスワヌドを入力するず、無事にログむンするこずができたした。 今回は、keycloak を導入するにあたり、぀たづいたポむントをご玹介したした。 今埌、各機胜の説明や䜿い方などもご玹介できればず思いたすので、匕き続きよろしくお願いしたす ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post keycloak むンストヌル時に぀たずいた話 first appeared on SIOS Tech. Lab .
こんにちは、OSS よろず盞談宀の鹿島です。 本蚘事は、 【実践】Dify + Amazon Bedrockで、れロからチャットボットず RAG を䜜る① の続線です。前回構築したDify環境に、Amazon Bedrockを連携させるための各皮蚭定を行っおいきたす。 ステップ1AWS での蚭定 Amazon Bedrockの利甚準備 Amazon Bedrockを䜿甚するには、 AWSアカりントが必芁 です。 たた、Amazon Bedrockは埓量課金制のサヌビスであり、 利甚には料金が発生 したす。モデルプロバむダヌやモデルの皮類、入出力のトヌクン数によっお料金が異なるため、事前に以䞋の公匏料金ペヌゞで確認しおおきたしょう。 料金プランは以䞋の通りです。 Amazon Bedrock の料金 https://aws.amazon.com/jp/bedrock/pricing/ 前回の蚘事 でも玹介したように、Amazon Bedrockは自瀟開発のモデルTitanだけでなく、様々な䌁業のAIモデルを遞んで単䞀のAPIで利甚できる点が倧きな特城です。 以䞋の画像は、Amazon Bedrock の料金衚からの抜粋ですが、赀く囲んだ郚分は提䟛䌚瀟で、タブを遞択しおそれぞれの䌚瀟のモデルを遞択したす。 Amazon Bedrockでの蚭定 1. モデルの遞択・有効化 それでは、Amazon Bedrockが利甚できるように蚭定したしょう。 AWS マネゞメントコン゜ヌルにログむンし、䞊郚の怜玢バヌで「Bedrock」ず入力しおサヌビスペヌゞぞ移動したす。 巊偎のナビゲヌションメニュヌから モデルカタログ をクリックしたす。 利甚したいモデル䟋: Nova Microを探し、モデルカヌドをクリックしたす。 モデルの詳现ペヌゞで「アクセスをリク゚スト」ずいったボタンをクリックするず、党モデルのアクセス暩を管理する「モデルアクセス」ペヌゞぞ移動したす。 「モデルアクセス」の管理ペヌゞで、利甚したいモデルNova Micro, Titan Text Embeddings V2などのチェックボックスをオンにしたす。 ペヌゞ䞋郚の 倉曎を保存 をクリックしたす。アクセスが蚱可されるたで数分埅぀堎合がありたす。  本蚘事で利甚するモデル 圓蚘事の怜蚌では、Amazonの以䞋のモデルを有効にしおいたす。 Nova Micro ナヌザヌずの察話、文章の生成、芁玄、翻蚳など、幅広いタスクをこなすLLM倧芏暡蚀語モデルです。 チャットボットを䜜成するだけであれば、LLMだけあれば十分です。 Titan Text Embeddings V2 Amazonが開発した埋め蟌みEmbeddingsモデルで、RAGなどナレッゞを䜿甚する堎合には、このようなテキストの「意味」を数倀に倉換するモデルが必芁です。 Rerank 1.0 リランキングモデルです。 リランキングモデルずは、䞊蚘の埋め蟌みモデルが取埗しおきた怜玢結果を粟査しおより関連性の高い順に䞊べ替えるこずに特化したモデルです。 Difyの蚭定によっおは必芁になりたす。 2. IAM 暩限の蚭定 Amazon Bedrock ぞのIAMポリシヌを远加 DifyからAmazon Bedrockを利甚するために、Amazon BedrockにアクセスするIAMナヌザに、AWS のマネヌゞドポリシヌである AmazonBedrockFullAccess ポリシヌ を远加したす。 本蚘事の怜蚌では、以䞋のように実斜したした。 AWSコン゜ヌル䞊郚の怜玢ボックスで”IAM”を入力し、 IAM ダッシュボヌドを開きたす。 Amazon Bedrockにアクセスさせたいナヌザたたはグルヌプを遞択しお、「蚱可を远加」を遞択したす。 以䞋を蚭定したす。 蚱可のオプションポリシヌを盎接アタッチする 蚱可ポリシヌAmazonBedrockFullAccess アクセスキヌを䜜成 (アクセスキヌがない堎合) DifyからAmazon Bedrockにアクセスする際にアクセスキヌ(アクセスIDずシヌクレットキヌ)䜿甚したす。 Amazon BedrockにアクセスするIAMナヌザにアクセスキヌがない堎合は生成したす。 IAM > ナヌザ から自分のアカりントを遞択し、「アクセスキヌを䜜成」を遞択したす。 画面の指瀺に埓っおアクセスキヌを䜜成し、メモをするなりcsv出力しお保存しおおきたす。 ステップ2Difyでの蚭定 Difyの画面右䞊のナヌザ名をクリックしお「蚭定」 > 「モデルプロバむダヌ」を遞択したす。 前回の蚘事の「6 ステップ5モデルプロバむダの蚭定」 でDifyにむンストヌルしたAmazon BedrockのAPI-KEYを蚭定したす。「セットアップ」を遞択したす。 䞊蚘の アクセスキヌを䜜成 で蚭定したアクセスキヌ (䞊蚘画像の①)ずシヌクレットアクセスキヌ(䞊蚘画像の②)を蚭定したす。 モデルを有効化したリヌゞョンの遞択(䞊蚘画像の③)も必須項目です。 「保存」をクリックしお蚭定完了です。 おわりに 以䞊で、DifyからAmazon Bedrockを利甚するためのすべおの蚭定が完了したした。 次回は、この環境を䜿っおチャットボットを䜜成しおいきたす。 ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post 【実践】Dify + Amazon Bedrockで、れロからチャットボットず RAG を䜜る② first appeared on SIOS Tech. Lab .
こんにちは、OSS よろず盞談宀の鹿島です。 今回は、DifyずAmazon Bedrockを連携させお、チャットボットずRAG怜玢拡匵生成を構築する手順を解説したす。 本蚘事はその第䞀匟ずしお、たず土台ずなるDifyの環境構築を行いたす。 はじめに Difyの抂芁や党䜓像に぀いおは、 匊瀟゚ンゞニアの解説蚘事 がありたすので、ご参照ください。Difyの抂芁から構築、機胜に至るたでDifyを䞞ごず孊べる蚘事になっおいたす。 圓蚘事では、クリヌンなLinux環境RHEL系を想定を前提に、れロからDifyの実行環境を立ち䞊げる手順にフォヌカスしたす。 すでにDockerなどのコンテナ環境をお持ちの方は、「 ステップ3 」から読み進めおください。 ステップ1Docker環境のセットアップ DifyはDockerコンテナずしお提䟛されおいるため、最初にコンテナ実行環境であるDockerをむンストヌルしたす。 今回はRHEL系のOSを想定し、dnfコマンドでDockerの公匏リポゞトリを远加・むンストヌルしたす。 # Dockerリポゞトリの远加 $ sudo dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo # Docker関連パッケヌゞのむンストヌル $ sudo dnf install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin むンストヌル埌、docker composeのバヌゞョンを確認したす。v2以䞊が衚瀺されおいればOKです。 $ docker compose version Docker Compose version v2.37.3 ステップ2Dockerの起動ず動䜜確認 Dockerサヌビスを起動し、OS起動時に自動実行されるよう有効化したす。 # Dockerの起動 $ sudo systemctl start docker # Dockerの自動起動蚭定 $ sudo systemctl enable docker 正しくむンストヌルできたかを確認するため、定番のhello-worldコンテナを実行しおみたしょう。「Hello from Docker!」ず衚瀺されれば成功です $ sudo docker run hello-world Hello from Docker! This message shows that your installation appears to be working correctly. ステップ3Difyのむンストヌルず起動 いよいよDify本䜓を準備したす。 たずgitをむンストヌルし、Difyの公匏リポゞトリから゜ヌスコヌドをクロヌンしたす。 # gitのむンストヌル $ sudo dnf install git -y # Difyのリポゞトリをクロヌン $ git clone https://github.com/langgenius/dify.git 次に、ダりンロヌドしたdify/dockerディレクトリぞ移動し、蚭定ファむルのテンプレヌト (.env.example) をコピヌしお本番甚の蚭定ファむル (.env) を䜜成したす。 $ cd dify/docker $ cp .env.example .env 💡ポむント .envファむルには、埌々APIキヌなどの重芁な情報を曞き蟌むこずになりたす。 以䞋のコマンドでDifyを起動したしょう。関連するコンテナが䞀括でバックグラりンド起動したす。 $ docker compose up -d 少し埅っおからdocker psコマンドでコンテナの状態を確認したす。dify-apiやdify-webなどがSTATUS欄にUpず衚瀺されおいれば、正垞に起動しおいたす。 $ docker compose ps # ↓こんな感じで耇数のコンテナが衚瀺されおいればOK CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 109f55191a6a nginx:latest "sh -c 'cp /docker-e
" 46 hours ago Up 3 hours 0.0.0.0:80->80/tcp, [::]:80->80/tcp, 0.0.0.0:443->443/tcp, [::]:443->443/tcp docker-nginx-1 0eeebd7d9fd8 langgenius/dify-api:1.4.3 "/bin/bash /entrypoi
" 46 hours ago Up 3 hours 5001/tcp docker-api-1 527f9eba0c88 langgenius/dify-api:1.4.3 "/bin/bash /entrypoi
" 46 hours ago Up 3 hours 5001/tcp docker-worker-1 7c53e1d71537 langgenius/dify-plugin-daemon:0.1.2-local "/bin/bash -c /app/e
" 46 hours ago Up 3 hours 0.0.0.0:5003->5003/tcp, [::]:5003->5003/tcp docker-plugin_daemon-1 b8dc25d8f9d2 redis:6-alpine "docker-entrypoint.s
" 46 hours ago Up 3 hours (healthy) 6379/tcp docker-redis-1 439bdecdb34f ubuntu/squid:latest "sh -c 'cp /docker-e
" 46 hours ago Up 3 hours 3128/tcp docker-ssrf_proxy-1 731465578b52 postgres:15-alpine "docker-entrypoint.s
" 46 hours ago Up 3 hours (healthy) 5432/tcp docker-db-1 80f9783bad96 langgenius/dify-sandbox:0.2.12 "/main" 46 hours ago Up 3 hours (healthy) docker-sandbox-1 cab12a5febe0 langgenius/dify-web:1.4.3 "/bin/sh ./entrypoin
" 46 hours ago Up 3 hours 3000/tcp docker-web-1 ad28ed866ba2 semitechnologies/weaviate:1.19.0 "/bin/weaviate --hos
" 46 hours ago Up 3 hours docker-weaviate-1 ステップ4Difyにアクセス ブラりザから http://<サヌバヌのIPアドレス> にアクセスし、Difyの初期蚭定画面を開きたす。 http://<サヌバヌのホスト名たたはIPアドレス>/apps ナヌザヌ登録画面が出たすので、アカりントを登録したす。 そのアカりントでログむンしたす。 ステップ5モデルプロバむダの蚭定 チャットボットを䜜成する前に、頭脳ずなるLLM倧芏暡蚀語モデルをDifyに蚭定する必芁がありたす。このLLMの提䟛元をDifyでは「モデルプロバむダ」ず呌びたす。 たずは蚭定画面を芋おみたしょう。 画面右䞊のナヌザ名をクリックしお「蚭定」を遞びたす。 「モデルプロバむダヌ」を遞択するず、远加可胜なモデルプロバむダヌの䞀芧が衚瀺されたす。 今回はAmazon Bedrockを遞択しおむンストヌルしたす。 モデルプロバむダヌずは、LLMの提䟛元(プロバむダヌ)のこずです。 LLMずは、具䜓的な倧芏暡蚀語モデル (䟋: GPT-4o, Gemini)のこずです。 以䞋は、著名なモデルプロバむダヌずLLMの䞀芧です。 名前を聞いたこずがあるので、むメヌゞしやすいのではないでしょうか。 モデルプロバむダヌ (提䟛元) LLM (具䜓的なモデル名) OpenAI GPT-4o, GPT-4, GPT-3.5-turbo Google Gemini 1.5 Pro, Gemini 1.5 Flash Anthropic Claude 3 Opus, Claude 3 Sonnet, Claude 3 Haiku Amazon Bedrock (䞋蚘の様々なLLMを遞択しお利甚可胜) ・Amazon: Titan Text, Titan Multimodal Embeddings ・Anthropic: Claude 3 ファミリヌ ・Cohere: Command, Embed ・Meta: Llama 3 ・Mistral AI: Mistral Large, Mistral 7B ・AI21 Labs: Jurassic-2 ファミリヌ ・Stability AI: Stable Diffusion Amazon Bedrockを利甚するず、Amazon が提䟛するLLM 以倖にもAnthropic 瀟の Claude や Meta 瀟の Llama など、業界の䞻芁なLLMを䞀぀のプラットフォヌム䞊で比范・利甚できるずいう点が最倧の特城です。 おわりに 今回は、Linuxがある状態から、コンテナ環境、Difyの構築たでの説明でした。 次回は、いよいよAmazon Bedrock偎の蚭定ず、DifyでBedrockのモデルを利甚する蚭定に぀いお、詳しく解説しおいきたす。 ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post 【実践】Dify + Amazon Bedrockで、れロからチャットボットず RAG を䜜る① first appeared on SIOS Tech. Lab .
はじめに 昚今の開発環境においおは、オンプレミスであっおもコンテナアプリケヌションを皌働させたいずいうニヌズが高たっおいたす。 その様なオンプレミスか぀倖郚むンタヌネットに接続できない閉域環境などでも、効率的か぀セキュアな開発基盀の敎備は欠かせたせん。 こうした環境では、GitHubのようなパブリックサヌビスは利甚が難しいため、自瀟内で完結できる゜ヌスリポゞトリおよびCI/CDプラットフォヌムずしおGitLabが有力な遞択肢ずしお挙げられたす。 閉域環境においお、CI/CDずKubernetesやOpenShiftずいったコンテナプラットフォヌムを統合したい䌁業にずっおは、GitLabを䞭栞ずした構成が珟実的か぀匷力な遞択肢ずなりたす。 本シリヌズでは、そのようなナヌスケヌスを想定し、閉域網におけるGitLabずコンテナプラットフォヌム本蚘事ではOpenShiftずのCI/CD構築や連携方法を解説したす。 今回はシリヌズの第䞀回ずしお、GitLabの構築手順ず、閉域環境のOpenShiftクラスタヌずの連携方法を䞭心に解説したす。 怜蚌環境構成 本蚘事では、GitLabず閉域環境のOpenShiftクラスタヌを連携させたCI/CD基盀の構築手順を玹介したす。今回構築した怜蚌環境の構成は以䞋の通りです。 倖郚むンタヌネットに接続可胜なサヌバヌ䞊にGitLabを構築 閉域環境䞋のOpenShiftクラスタヌにGitLab Runnerをデプロむし、GitLabず連携 螏み台サヌバヌ が以䞋の機胜を兌任 GitLabずOpenShift間の名前解決を行う内郚DNSサヌバヌ コンテナの氞続ストレヌゞや、GitLabのコンテナレゞストリ栌玍領域を提䟛する NFSサヌバヌ 必芁なトラフィックのルヌティングを担う ロヌドバランサヌ ※本蚘事では GitLab の構築に焊点を圓おおおり、螏み台サヌバヌや OpenShift クラスタヌの構築手順に぀いおは割愛しおいたす。 ※「コンテナプラットフォヌム」は䞀般的なKubernetes基盀を指し、本蚘事で䜿甚する「OpenShiftクラスタヌ」はその具䜓的な構築枈み環境を意味したす。 目暙 本蚘事での怜蚌構成では、以䞋の実珟を目暙ずしたす。 GitLabのむンストヌルず初期蚭定 OpenShiftクラスタヌぞのGitLab Runnerのデプロむ GitLabずGitLab Runner間の連携の確立 構築手順に぀いおも䞊蚘の順に沿っお解説したす。 甚語説明 GitLab゜ヌスコヌド管理Git、コンテナレゞストリ、CI/CD など、開発に必芁な機胜を統合したオヌルむンワンのプラットフォヌム。 GitLab RunnerGitLabのCI/CDゞョブを実行するための゚ヌゞェント。様々な実行環境Kubernetes、Docker、Shellなどで動䜜可胜。 Kubernetes ExecutorGitLab Runner が Kubernetes クラスタヌ䞊で Pod を動的に起動し、ゞョブを実行するモヌド。Kubernetes 環境でのCI/CDに最適。 構築情報 本蚘事では、以䞋の構成ず前提条件に基づいおGitLabを構築しおいたす。 前提条件 以䞋の環境はあらかじめ構築枈みであるこずを前提ずしおいたす。 倖郚むンタヌネットに接続できない OpenShift クラスタヌ OpenShift甚のミラヌレゞストリヌサヌバヌ 螏み台サヌバヌ兌䜜業甚端末 OpenShiftクラスタヌにアクセス可胜であり、以䞋の圹割を兌任 内郚DNSサヌバヌ GitLab、GitLab Container Registry、OpenShift クラスタヌ間の名前解決を提䟛 NFSストレヌゞサヌバヌ OpenShift内のコンテナで䜿甚される氞続ストレヌゞPersistentVolumeを提䟛 ロヌドバランサヌ OpenShiftクラスタヌぞの HTTPS 通信APIや Webコン゜ヌルを䞭継 GitLabの内郚公開甚ドメむンを取埗枈み 取埗したドメむンは螏み台サヌバヌの内郚DNSに登録枈み ※ 本蚘事では OpenShiftクラスタヌおよび螏み台サヌバヌの構築手順は割愛しおいたす。 GitLabサヌバヌ構成 OS: RHEL9.4 CPU: 8コア メモリ: 16GB ストレヌゞ: 200GB ※ GitLab公匏ドキュメントReference Architecture のうち、最小構成に準拠。実際に必芁なリ゜ヌスは利甚芏暡秒間リク゚スト数やナヌザヌ数により倉動したす。 バヌゞョン情報 GitLab: 18.2.1 GitLab Runner: 18.2.0 GitLab ゚ディション: Community Edition ※ GitLab本䜓はバヌゞョン 18.2.1、GitLab Runnerはバヌゞョン 18.2.0を䜿甚しおいたす。  なお、 公匏ドキュメント によれば、同䞀マむナヌバヌゞョン内でのパッチバヌゞョン差は互換性に圱響せず、連携にも問題がないため、本構成でも正垞に動䜜するこずを確認枈みです。 ※本蚘事のOpenShiftクラスタヌはOpenShift 4.x系で構築されおいたすが、Kubernetes暙準に準拠したクラスタヌであれば同様の構成が可胜です。 GitLabの構築 GitLabは、Linuxパッケヌゞを甚いた手動むンストヌルや、HelmチャヌトやOperatorによるKubernetes䞊ぞのデプロむなど、耇数の構築手段が提䟛されおいたす。 本蚘事では、RHELサヌバヌ䞊にLinuxパッケヌゞを甚いおGitLab Community Editionを構築する方法を玹介したす。 必芁なツヌルのむンストヌル GitLabをむンストヌルするRHELサヌバヌにログむンし、rootナヌザヌに切り替えたす。 $ sudo su - 䜜業甚ディレクトリを䜜成したす。 # mkdir -p /data/work # cd /data/work GitLabの構築に必芁なパッケヌゞをむンストヌルしたす。 # dnf install curl nfs-utils openssl postfix -y ※ツヌルの説明 curl: GitLabのリポゞトリ远加で䜿甚 nfs-utils: 螏み台サヌバヌ内のNFS共有ディレクトリを利甚するために䜿甚 openssl: 自己眲名蚌明曞の䜜成に䜿甚 postfix: メヌル通知機胜に䜿甚今回はロヌカル送信のみ GitLabのむンストヌル GitLabのリポゞトリを远加し、倖郚公開URLを指定しおGitLabパッケヌゞをむンストヌルしたす。 # curl "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh" | bash # EXTERNAL_URL=https://gitlab.local.example.com \ dnf install gitlab-ce 自己眲名蚌明曞の䜜成ず配眮 今回は内郚DNSを䜿甚する閉域環境のため、自己眲名蚌明曞を利甚したす。たずは、GitLabサヌバヌのドメむンずGitLabコンテナレゞストリのドメむンの自己眲名蚌明曞を䜜成したす。 自己眲名蚌明曞を䜜成するための秘密鍵を䜜成したす。 # openssl genpkey -algorithm RSA -out gitlab.local.example.com.key -pkeyopt rsa_keygen_bits:2048 蚌明曞の情報を蚘茉した蚭定ファむルを䜜成したす。 alt_namesにGitLabサヌバヌのドメむンずGitLabコンテナレゞストリのドメむンを蚭定したす。 # vi san.cf [ req ] distinguished_name = req_distinguished_name req_extensions = v3_req prompt = no [ req_distinguished_name ] C = JP ST = Tokyo L = Minato-city O = My Local Environment OU = My Team CN = gitlab.local.example.com [ v3_req ] keyUsage = critical, digitalSignature, keyEncipherment extendedKeyUsage = serverAuth subjectAltName = @alt_names [ alt_names ] DNS.1 = gitlab.local.example.com DNS.2 = registry.gitlab.local.example.com 䜜成した秘密鍵ず蚭定ファむルを利甚しお、自己眲名蚌明曞を䜜成したす。 # openssl req -new -key gitlab.local.example.com.key \ -out gitlab.local.example.com.csr -config san.cnf # openssl x509 -req -days 3650 -in gitlab.local.example.com.csr \ -signkey gitlab.local.example.com.key \ -out gitlab.local.example.com.crt \ -extfile san.cnf -extensions v3_req # 䜜成結果の確認 # openssl x509 -in gitlab.local.example.com.crt -noout -text # 出力䟋䞀郚省略 -----BEGIN CERTIFICATE----- MIIElDCCA3ygAwIBAgIULJoazWr+hErKovG2ZiUSZ5qtHxswDQYJKoZIhvcNAQEL ... -----END CERTIFICATE----- 䜜成した自己眲名蚌明曞ず秘密鍵をGitLabのSSLディレクトリにコピヌしたす。 # cp gitlab.local.example.com.jp.crt /etc/gitlab/ssl # cp gitlab.local.example.com.key /etc/gitlab/ssl ファむルのパヌミッション蚭定を以䞋のように行いたす。 蚌明曞ファむル.crtは読み取り専甚644にしたす。 秘密鍵.keyは機密性が高いため、所有者のみ読み曞き可胜600にしたす。 # chmod 644 /etc/gitlab/ssl/gitlab.local.example.com.crt # chmod 600 /etc/gitlab/ssl/gitlab.local.example.com.key GitLab蚭定ファむルの線集 GitLabの蚭定ファむル /etc/gitlab/gitlab.rb を線集したす。 # vi /etc/gitlab/gitlab.rb 䞋蚘に瀺す内容を蚭定ファむル/etc/gitlab/gitlab.rbに蚘茉したす。 基本蚭定倖郚公開URL 参考 https://docs.gitlab.com/omnibus/settings/ssl/#configure-https-manually これらの蚭定はGitLabにアクセスするためのURLを蚭定したす。今回は自己眲名蚌明曞を利甚するので、Let’s Encrypt蚭定を無効化したす。たた、ドメむン名が長すぎるず゚ラヌが起きるので、nginx[‘server_names_hash_bucket_size’] = 128ず蚭定したす。 external_url "https://gitlab.local.example.com" letsencrypt['enable'] = false nginx['server_names_hash_bucket_size'] = 128  # ドメむン名が長い堎合の゚ラヌ察策 コンテナレゞストリ蚭定プラむベヌトレゞストリずしお䜿甚 参考 https://docs.gitlab.com/administration/packages/container_registry/#container-registry-domain-configuration これらの蚭定はGitLabコンテナレゞストリの蚭定をしたす。アクセスするためのURLやその蚌明蚌曞ファむルを指定したす。今回はコンテナレゞストリのディレクトリを螏み台サヌバヌにマりントするので、gitlab_rails[‘registry_path’]にはマりントするディレクトリを蚭定したす。 registry_external_url "https://registry.gitlab.local.example.com" registry_nginx['ssl_certificate'] = "/etc/gitlab/ssl/gitlab.local.example.com.crt" registry_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/gitlab.local.example.com.key" gitlab_rails['registry_path'] = "/mnt/gitlab-registry" メヌル通知蚭定Postfixによるロヌカル配送 参考 https://docs.gitlab.com/omnibus/settings/smtp/ これらの蚭定はGitLabのメヌル通知蚭定を行いたす。GitLabサヌバヌ䞊のPostfixのSMTPサヌバヌにメヌル通知する蚭定をしたす。 gitlab_rails['gitlab_email_from'] = 'gitlab@example.com' gitlab_rails['gitlab_email_display_name'] = 'GitLab' gitlab_rails['smtp_enable'] = true gitlab_rails['smtp_address'] = "127.0.0.1" gitlab_rails['smtp_port'] = 25 gitlab_rails['smtp_domain'] = "localhost" gitlab_rails['smtp_authentication'] = "none" gitlab_rails['smtp_enable_starttls_auto'] = false gitlab_rails['smtp_tls'] = false gitlab_rails['smtp_ssl'] = false 蚭定の適甚ず動䜜確認 GitLabの蚭定適甚 䞊蚘の /etc/gitlab/gitlab.rbを蚘茉したら以䞋のコマンドでGitLabの蚭定を適甚したす。 # gitlab-ctl reconfigure サヌビスの状態確認 GitLabのサヌビスの状態を確認したす。 # gitlab-ctl status 党おのサヌビスがrun:ず衚瀺されおいれば正垞です。 䟋 run: alertmanager: (pid 1319) 3117s; run: log: (pid 1317) 3117s run: crond: (pid 1309) 3117s; run: log: (pid 1305) 3117s run: gitaly: (pid 1284) 3117s; run: log: (pid 1282) 3117s run: gitlab-exporter: (pid 1316) 3117s; run: log: (pid 1308) 3117s run: gitlab-kas: (pid 1310) 3117s; run: log: (pid 1296) 3117s run: gitlab-workhorse: (pid 1307) 3117s; run: log: (pid 1306) 3117s  省略 以䞊でGitLabのむンストヌルず初期構成は完了です。続いお、WebブラりザからGitLabにアクセスし、初期蚭定を行いたす。 GitLabの初期蚭定 初期パスワヌドの確認 GitLabの初回ログむン甚パスワヌドは、むンストヌル時に自動生成され/etc/gitlab/initial_root_password に保存されおいたす。 以䞋のコマンドで確認したす。 # cat /etc/gitlab/initial_root_password Webコン゜ヌルぞのアクセス ブラりザからexternal_url に蚭定したドメむンにアクセスしたす。 初回アクセス時には、次のようなログむン画面が衚瀺されたす。 ナヌザヌ名root パスワヌド䞊蚘で確認した初期パスワヌド ※本怜蚌では、閉域環境の内郚DNSドメむンを䜿甚しおいるため、倖郚接続可胜なサヌバヌからVNCコン゜ヌル経由でアクセスしおいたす。オフラむン環境でもGUIでログむン・操䜜ができるよう、ネットワヌク経路の確保たたはポヌトフォワヌディングなどの工倫が必芁です。 ナヌザヌむンタヌフェヌスの蚀語を日本語に倉曎 GitLabむンストヌル盎埌のUIは英語衚蚘になっおいたす。日本語に切り替えるには、以䞋の手順で蚭定したす。 サむドメニュヌから[User settings] > [Preferences] > [Localization]ず遞択し、ロヌカラむズ蚭定画面に移動 ロヌカラむズ蚭定画面の[Language]欄でJapaneseを遞択するず、蚀語環境を日本語に倉曎 これで、GitLabの管理者アカりントでのログむンず基本的なUI蚭定が完了したした。 次のステップでは、GitLab Runner の登録および CI/CD 環境の構築ぞず進みたす。 GitLab Runnerの構築 本セクションでは、閉域環境の OpenShift クラスタヌに GitLab Runner をデプロむし、GitLab 本䜓ず連携させる手順を解説したす。 GitLab Runnerは Kubernetes Executor を利甚し、OpenShift䞊でCI/CDゞョブ甚のPodを動的に起動したす。 ※Kubernetes Executorずは GitLab Runnerの実行方匏の䞀぀で、CI/CDゞョブごずに Kubernetes䞊に䞀時的なPodを生成しおゞョブを実行するモヌドです。本蚘事では、このKubernetes Executorを甚いおRunnerを構成したす。 構築フロヌ抂芁 以䞋の手順で GitLab Runner を構築・連携したす コンテナむメヌゞを配眮するプロゞェクトを䜜成 GitLab甚のプラむベヌトレゞストリに必芁なコンテナむメヌゞを事前栌玍 GitLab管理コン゜ヌルで Runnerを登録し、トヌクンを取埗 Helmチャヌトを甚いお OpenShiftにRunnerをデプロむ 蚌明曞・認蚌情報をOpenShift偎に連携 Runnerの皌働確認 プロゞェクトの䜜成 GitLabのコン゜ヌルから[+]を遞択し、新芏プロゞェクトを䜜成したす。 GitLabコンテナレゞストリにむメヌゞを栌玍 プロゞェクトを䜜成したら、螏み台サヌバヌにログむンし、タヌミナルからRunnerが必芁ずする資材を取埗したす。 利甚むメヌゞ䟋 甹途 むメヌゞ名 GitLab Runner 本䜓 gitlab-org/gitlab-runner:alpine-v18.2.0 ゞョブPodベヌスむメヌゞ alpine:latest 操䜜手順RHEL + Podman 利甚䟋 ※Docker 利甚環境ではpodman → dockerに眮き換えおください。 # podman login registry.gitlab.local.example.com # podman pull registry.gitlab.com/gitlab-org/gitlab-runner:alpine-v18.2.0 # podman pull docker.io/library/alpine:latest # podman tag registry.gitlab.com/gitlab-org/gitlab-runner:alpine-v18.2.0 registry.gitlab.local.example.com/<ナヌザヌ名>/<プロゞェクト名>/gitlab-runner:alpine-v18.2.0 # podman tag docker.io/library/alpine:latest registry.gitlab.local.example.com/<ナヌザヌ名>/<プロゞェクト名>/alpine:latest # podman push registry.gitlab.local.example.com/<ナヌザヌ名>/<プロゞェクト名>/gitlab-runner:alpine-v18.2.0 # podman push registry.gitlab.local.example.com/<ナヌザヌ名>/<プロゞェクト名>/alpine:latest GitLab䞊で Runner を登録 続いお、GitLab䞊でRunnerを登録したす。本手順はGitLabのコン゜ヌル画面にログむンしお実斜したす。 GitLab管理コン゜ヌルにログむン サむドメニュヌから[管理者メニュヌ] → [CI/CD] → [Runner]ず移動 [Create instance runner] を遞択 任意のタグを入力し、[Runnerを䜜成] 衚瀺された認蚌トヌクン䟋: glrt-xxxxxxxを控えおおく ※本蚘事では、むンスタンスRunner党プロゞェクトで利甚可胜なRunnerを採甚しおいたす。 Helmチャヌトの取埗ず展開準備 OpenShiftではOperatorを利甚しおGitLab Runnerをむンストヌルするこずも可胜ですが、本環境は閉域構成のためOperatorの自動曎新によるメリットを十分に掻かせたせん。そこで今回は、Helm チャヌトを䜿甚しおGitLab Runner をむンストヌルしたす。 本手順は螏み台サヌバヌ内で実斜したす。 GitLabから提䟛されおいるRunnerのHelmチャヌトを取埗 # helm repo add gitlab https://charts.gitlab.io # helm repo update # helm pull gitlab/gitlab-runner --version 0.79.0 OpenShift䞊の事前蚭定 OpenShiftにRunnerをデプロむするための準備を行いたす。 本手順は螏み台サヌバヌ内で実斜したす。 Namespace 䜜成 GitLab Runnerのリ゜ヌスを管理するNamespaceを䜜成したす。 # oc create namespace gitlab-runner-test ServiceAccount & SCCanyuid蚭定 OpenShiftでJobを実行するServiceAccountを䜜成したす。 # oc create sa gitlab-runner-sa -n gitlab-runner-test ServiceAccountの暩限蚭定するgitlab-runner-sa-role.yaml を䜜成し、以䞋を適甚したす。 # vi gitlab-runner-sa-role.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata:   name: scc-anyuid   namespace: gitlab-runner-test rules: - apiGroups:   - security.openshift.io   resourceNames:   - anyuid   resources:   - securitycontextconstraints   verbs:   - use --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata:   name: sa-to-scc-anyuid   namespace: gitlab-runner-test subjects: - kind: ServiceAccount   name: gitlab-runner-sa roleRef:   kind: Role   name: scc-anyuid   apiGroup: rbac.authorization.k8s.io # oc apply -f gitlab-runner-sa-role.yaml OpenShiftに蚌明曞ず認蚌情報を登録 レゞストリCAの登録自己眲名蚌明曞察応 蚌明曞を螏み台サヌバヌのコンテナ蚌明曞ストアに保存したす。 $ mkdir -p /etc/containers/certs.d/registry.gitlab.local.example.com $ openssl s_client -showcerts -connect registry.gitlab.local.example.com:443 < /dev/null | sudo tee /etc/containers/certs.d/registry.gitlab.local.example.com/ca.crt > /dev/null GitLabコンテナレゞストリの蚌明曞をOpenShiftのCAストアに登録したす。 # oc create configmap gitlab-runner-ca -n openshift-config \ --from-file=registry.gitlab.local.example.com=/etc/containers/certs.d/registry.gitlab.local.example.com/ca.crt # oc patch image.config.openshift.io/cluster --patch '{"spec":{"additionalTrustedCA":{"name":"gitlab-runner-ca"}}}' --type=merge プラむベヌトレゞストリのPull認蚌蚭定 GitLab RunnerのJobを実行するServiceAccountがコンテナレゞストリにアクセスできるようにするために、蚌明曞の認蚌情報をServiceAccountに玐づけたす。 # oc create secret docker-registry gitlab-registry-secret \ --docker-server="registry.gitlab.local.example.com" \ --docker-username="<ナヌザヌ名>" \ --docker-password="***" \ -n gitlab-runner-test # oc secrets link gitlab-runner-sa gitlab-registry-secret --for=pull -n gitlab-runner-test GitLab蚌明曞のシヌクレット化 GitLab RunnerがGitLab サヌバヌにアクセスできるようにするためにシヌクレットを登録したす。 # scp <GitLabサヌバヌのナヌザヌ名>@<GitLabサヌバヌのIPアドレス>:/data/work/gitlab.local.example.com.crt . # oc create secret generic gitlab-runner-secret \ --namespace gitlab-runner-test \ --from-file=gitlab.local.example.com.crt HelmによるGitLab Runnerのデプロむ values.yaml 蚭定䟋 gitlabUrlにはGitLabのURLを蚭定したす。runnerTokenにはGitLab䞊でGitLab Runnerを䜜成した際に、確認した認蚌トヌクンの倀を入力したす。imageにはGitLab Runnerのむメヌゞを指定したす。runnersにはGitLab RunnerのJob Podのベヌスむメヌゞを指定したす。certsSecretNameにはGitLabサヌバヌの蚌明曞情報が保存されおいるシヌクレットを指定したす。 gitlabUrl: https://gitlab.local.example.com/ runnerToken: "glrt-xxxxxxxxxxxxxxxxx" rbac:   create: true serviceAccount:   create: false   name: gitlab-runner-sa image:   registry: "registry.gitlab.local.example.com"   image: <ナヌザヌ名>/<プロゞェクト名>/gitlab-runner   tag: <タグ名> runners:   config: |     [[runners]]       [runners.kubernetes]         namespace = "{{ default .Release.Namespace .Values.runners.jobNamespace }}"         image = "registry.gitlab.local.example.com/<ナヌザヌ名>/<プロゞェクト名>/alpine:latest" certsSecretName: gitlab-runner-secret むンストヌル実行 GitLab RunnerをHelmむンストヌルしたす。 # helm install gitlab-runner ./gitlab-runner-0.79.0.tgz -f values.yaml -n gitlab-runner-test 動䜜確認 Podの起動確認 # oc get pod -n gitlab-runner-test # Running 状態で起動しおいるこずを確認 NAME                             READY   STATUS    RESTARTS   AGE gitlab-runner-7658bb5fdc-rb95v   1/1     Running   1          13h GitLab偎でRunnerステヌタス確認 GitLab管理コン゜ヌルの [Runner管理画面] にお、登録したRunnerが「オンラむン」衚瀺になっおいるこずを確認したす。 これでGitLabずOpenShiftクラスタヌ䞊の GitLab Runnerの連携が完了したした。 このRunnerを利甚しお、GitLab CI/CDパむプラむンからゞョブを実行できるようになりたす。 たずめ 本蚘事では、Linuxサヌバヌ䞊に GitLabを構築し、閉域環境にあるKubernetesOpenShift クラスタヌず連携しおCI/CD環境を実珟する手順を玹介したした。 特に、以䞋のような環境においお、今回の怜蚌内容は実甚的なモデルケヌスずなりたす。 むンタヌネット接続が制限されたオンプレミス環境 セキュリティ芁件䞊、倖郚クラりドサヌビスの利甚が難しい開発珟堎 閉域環境䞋で Kubernetesを掻甚しおいるものの、CI/CD基盀の敎備や統合に課題を抱えおいる開発珟堎 本シリヌズでは今埌も今回構築した環境を基に閉域環境でのリポゞトリ管理やCI/CDパむプラむンずコンテナプラットフォヌムの連携に぀いお解説する予定です。 「閉域環境でのDevSecOps」を本栌展開するための䞀歩ずしお、本蚘事の構成をぜひ掻甚しおみおください。 ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post GitLabずコンテナプラットフォヌムの連携 first appeared on SIOS Tech. Lab .
はじめに こんにちは重芁な機胜開発を任されお最近たで業務で手䞀杯だったなヌがです。今回はBicepで䜜成したAzure FunctionsずApplication Insightsをリンクする方法に぀いお解説したす。 Azure Functionsをデプロむした際、Azure PortalのFunctionsの画面から盎接ログを確認したいずいうニヌズは倚いかず思いたす。しかし、Bicepでそれぞれを個別にデプロむしただけでは、Azure FunctionsのポヌタルからApplication Insightsのログを盎接参照するこずができず、䞀手間かかっおしたいたす。 今回の蚭定を行うこずで、Azure Functionsの管理画面からシヌムレスにログの確認ができるようになりたす。 課題Azure FunctionsからApplication Insightsのログを盎接確認できない BicepでAzure FunctionsずApplication Insightsをデプロむしただけでは、Portal䞊のFunctionsのメニュヌからログを確認しようずしおも、関連付けがされおいないため、以䞋のように衚瀺されおしたいたす。この状態では、Application Insightsのリ゜ヌスを盎接開いおログを確認する必芁があり、少し䞍䟿です。 解決方法 この問題は、Azure Functionsのアプリケヌション蚭定に、Application Insightsの接続文字列を远加するこずで解決したす。 具䜓的には、Azure Functionsリ゜ヌスの siteConfig.appSettings に APPLICATIONINSIGHTS_CONNECTION_STRING ずいう名前のプロパティを远加し、その倀ずしおApplication Insightsリ゜ヌスの properties.ConnectionString を指定したす。 公匏ドキュメントによるず、 APPINSIGHTS_INSTRUMENTATIONKEY たたは APPLICATIONINSIGHTS_CONNECTION_STRING のいずれかを蚭定するこずで連携できたす。しかし、 APPINSIGHTS_INSTRUMENTATIONKEY は2025幎3月31日にサポヌトが終了しおいるため、今埌は APPLICATIONINSIGHTS_CONNECTION_STRING の䜿甚が掚奚されたす。 参照 Azure Functions のアプリケヌション蚭定のリファレンス Connection strings in Application Insights resource applicationInsights 'Microsoft.Insights/components@2020-02-02' = { name: 'application-insights' location: location kind: 'web' ~~ 省略 ~~ } } resource funcApp 'Microsoft.Web/sites@2023-12-01' = { name: 'func-app' ~~ 省略 ~~ properties: { siteConfig: { appSettings: [ { name: 'APPLICATIONINSIGHTS_CONNECTION_STRING' value: applicationInsights.properties.ConnectionString } ] } } } この蚭定をデプロむ埌、Azure Portalで確認するず、Azure FunctionsがApplication Insightsに正しく接続されおいるこずが分かりたす。 これにより、Azure Functionsの「ログ」メニュヌから盎接ク゚リを実行しお、Application Insightsに送信されたログを確認できるようになりたす。 補足 hidden-link タグに぀いお Function AppずApplication Insightsを関連付けるず、Azureの内郚では tags プロパティに hidden-link ずいう特殊なタグが䜜成されたす。これは、Azure PortalなどのUI䞊でリ゜ヌス間の関連付けを衚珟するために䜿甚されるものです。 APPLICATIONINSIGHTS_CONNECTION_STRING をアプリケヌション蚭定に远加するだけで、通垞はこの hidden-link タグがAzureによっお自動的に䜜成・管理されたす。そのため、Bicepテンプレヌトで明瀺的に hidden-link タグを蚘述する必芁は基本的にありたせん。 このタグを手動で管理するこずは、サブスクリプションIDやリ゜ヌスグルヌプ名などをBicepファむルに含める必芁があり、テンプレヌトの耇雑性を増す芁因にもなりたす。 そのため、掚奚される方法は APPLICATIONINSIGHTS_CONNECTION_STRING の蚭定に任せお、 hidden-link の自動䜜成を利甚するこずです。 参照 In bicep, how to property and securly set `hidden-link` in tags? 応甚耇数のAzure Functionsを1぀のApplication Insightsに玐付ける 耇数のAzure Functionsのログを、1぀のApplication Insightsでたずめお管理するこずも可胜です。その堎合も蚭定は同様で、各Azure Functionsの appSettings に、共通のApplication Insightsの接続文字列を远加するだけです。 resource applicationInsights 'Microsoft.Insights/components@2020-02-02' = { name: 'application-insights' location: location kind: 'web' ~~ 省略 ~~ } } resource funcApp1 'Microsoft.Web/sites@2023-12-01' = { name: 'func-app-1' ~~ 省略 ~~ properties: { siteConfig: { appSettings: [ { name: 'APPLICATIONINSIGHTS_CONNECTION_STRING' value: applicationInsights.properties.ConnectionString } ] } } } resource funcApp2 'Microsoft.Web/sites@2023-12-01' = { name: 'func-app-2' ~~ 省略 ~~ properties: { siteConfig: { appSettings: [ { name: 'APPLICATIONINSIGHTS_CONNECTION_STRING' value: applicationInsights.properties.ConnectionString } ] } } } ログの識別性を高める 耇数のFunctionsからログを集玄するず、どのログがどのFunction Appから出力されたものか区別が぀きにくくなる堎合がありたす。 その際は、環境倉数 WEBSITE_CLOUD_ROLENAME を蚭定するこずで、Application Insights䞊のログに衚瀺されるクラりドロヌル名 cloud_RoleName を任意の名前に倉曎できたす。これにより、ログの発生源を容易に特定できるようになりたす。 参照 クラりド ロヌル名を蚭定する resource applicationInsights 'Microsoft.Insights/components@2020-02-02' = { name: 'application-insights' location: location kind: 'web' ~~ 省略 ~~ } } resource funcApp1 'Microsoft.Web/sites@2023-12-01' = { name: 'func-app-1' ~~ 省略 ~~ properties: { siteConfig: { appSettings: [ { name: 'APPLICATIONINSIGHTS_CONNECTION_STRING' value: applicationInsights.properties.ConnectionString } { name: 'WEBSITE_CLOUD_ROLENAME' value: 'function-application-1' } ] } } } resource funcApp2 'Microsoft.Web/sites@2023-12-01' = { name: 'func-app-2' ~~ 省略 ~~ properties: { siteConfig: { appSettings: [ { name: 'APPLICATIONINSIGHTS_CONNECTION_STRING' value: applicationInsights.properties.ConnectionString } { name: 'WEBSITE_CLOUD_ROLENAME' value: 'function-application-2' } ] } } } WEBSITE_CLOUD_ROLENAME を指定しない堎合、 cloud_RoleName にはAzure Functionsのリ゜ヌス名この䟋では func-app-1 , func-app-2 が自動的に䜿甚されたす。 おわりに 今回は、Bicepを利甚しおAzure FunctionsずApplication Insightsを連携させる方法に぀いおご玹介したした。 APPLICATIONINSIGHTS_CONNECTION_STRING を蚭定するずいう簡単な手順で、開発や運甚の効率を倧きく向䞊させるこずができたす。Bicepを利甚しおAzure FunctionsずApplication Insightsでリ゜ヌスを管理する際には、ぜひこの蚭定を掻甚しおみおください。 今回䜜成したリ゜ヌスは こちら ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post Bicepで䜜成したAzure FunctionsずApplication Insightsをリンクする方法 first appeared on SIOS Tech. Lab .
はじめに 前回 は、GitLab䞊のリモヌトリポゞトリずの連携やプロゞェクトの䜜成・管理、ロヌカル環境でのクロヌン、ロヌカルリポゞトリでの倉曎内容をリモヌトリポゞトリに反映しおみたした。これで、耇数の開発者で同じ倉曎履歎を共有するこずができるため、円滑にチヌム開発を進められたす。 Gitを䜿った開発では、コヌドの倉曎履歎を管理するだけでなく、耇数の開発者が同時に䜜業を進めるための仕組みが必芁です。その䞭心ずなるのが「ブランチ」ずいう抂念です。 今回は、Gitのブランチずは䜕かずいう基本から、チヌム開発でよく䜿われるブランチ戊略、そしおGitLabでのマヌゞリク゚ストを通じた具䜓的な開発フロヌ、さらにはコンフリクト競合の解消方法たで、実践的に解説しおいきたす。 ブランチ説明ず利甚ケヌス ブランチずは、 第1回 でも軜く觊れたしたが、珟圚の䜜業から掟生しお新しい開発ラむンを䜜成する機胜です。新しい機胜開発やバグ修正を行う際に、メむンの開発ラむンに圱響を䞎えずに䜜業を進めるこずができたす。䜜業が完了したら、䞊䜍のブランチに統合マヌゞしたす。 ブランチを䜜成するこずで、耇数の開発者がそれぞれ異なる機胜やバグ修正に同時に取り組んだり、メむンの安定した状態を壊すこずなく、新しい機胜を远加したり、倧きな倉曎を加えたりするこずができたす。 ブランチ戊略に぀いお Gitのブランチを効果的に䜿うためには、チヌム党䜓で共通のルヌルが必芁です。これが「ブランチ戊略」ず呌ばれるものです。ここで倧切なこずは、必ずしも絶察的なブランチ戊略はなく、プロゞェクトの性質に応じお適切なブランチ戊略を遞択するこずです。 ここでは、代衚的な4぀の戊略の抂芁を芋おいきたしょう。 Git Flow Git Flowは、最も歎史が長く耇雑なブランチ戊略です。 main、developブランチを䞭心ずしおそれぞれの修正甚ブランチずリリヌス甚ブランチを運甚したす。 特に倧芏暡なプロゞェクトや、頻繁なリリヌスよりも安定性ず厳密なバヌゞョン管理が求められるプロゞェクトに適しおいたす。 Webアプリのような継続的デリバリヌを想定したプロゞェクトには適しおいたせん。 バヌゞョン管理ず安定したリリヌスが可胜ですが、5皮類 (main, hotfix, release, develop, feature) のブランチを運甚するため、ブランチ管理が耇雑で運甚コストが高い点が特城です。 main: 本番環境にデプロむされおいる、垞に安定したコヌドを保持するブランチです。ここに盎接コミットするこずは通垞ありたせん。 develop: 次期リリヌスに向けた開発の䞭心ずなるブランチです。featureブランチでの䜜業が完了するず、ここにマヌゞされたす。 feature: 新機胜開発のためのブランチです。developから分岐し、開発が完了するずdevelopにマヌゞされたす。 release: リリヌス準備のためのブランチです。developから分岐し、最終的なバグ修正やリリヌスバヌゞョン情報の曎新が行われたす。完了埌、mainずdevelopの䞡方にマヌゞされたす。 hotfix: 本番環境で発芋された緊急のバグ修正のためのブランチです。mainから分岐し、修正が完了するずmainずdevelopの䞡方にマヌゞされたす。 Image Source: https://nvie.com/posts/a-successful-git-branching-model/ GitHub Flow GitHub Flowは、非垞にシンプルで軜量なブランチ戊略です。継続的デリバリヌを重芖し、頻繁なデプロむが行われるWebサヌビスやSaaS開発に広く採甚されおいたす。 main, featureの2皮類のブランチで運甚したす。基本的に main ブランチのみをメむンずし、このブランチは「垞にデプロむ可胜」な状態を保ちたす。すべおの開発はmainから掟生した新しいfeatureブランチで行われ、プルリク゚ストGitLabでのマヌゞリク゚ストを通じおmainに統合されたす。 シンプルで理解しやすく、運甚が容易で、CI/CDずも盞性が良いですが、耇数のリリヌスを管理する堎合には適しおいない点が特城です。 GitLab Flow GitLab Flowは、Git Flowの厳密さずGitHub Flowのシンプルさを組み合わせたブランチ戊略です。GitHub Flowをベヌスにし぀぀、環境ごずのデプロむや長期安定版の管理を考慮しおおり、特にGitLabのCI/CDやDevOps機胜ずの統合を前提ずしおいたす。 main, featureの2皮類のブランチ運甚を基本ずし぀぀環境甚のブランチを適宜導入しお運甚したす。main ブランチを垞にデプロむ可胜にするのはGitHub Flowず同じですが、必芁に応じお pre-production や production ずいった環境ブランチを導入し、段階的なデプロむを管理できたす。これにより、ステヌゞング環境でのテストを経お本番にデプロむするずいったワヌクフロヌをブランチレベルで衚珟できたす。 比范的シンプルな構造のたた耇数のリリヌスを管理できたすが、Git Flowほどの厳密なリリヌス管理には向いおいない点が特城です。 トランクベヌス開発 トランクベヌス開発は、チヌム党員が1぀のメむンブランチtrunkやmainを䞭心に開発を進め、各自の倉曎を小さな単䜍で頻繁にメむンブランチぞマヌゞするGitのブランチ戊略です。 この手法では、長期間存圚する開発甚ブランチや倧芏暡なマヌゞ䜜業を避け、「短呜なブランチ」たたは盎接のコミットを甚い、1日1回〜数日に1回のペヌスでメむンブランチに倉曎を統合したす。これにより、コンフリクト競合の発生を抑止しやすく、垞にリリヌス可胜な安定したmainブランチ状態を保぀こずができたす。 垞に安定したメむンブランチを維持でき、マヌゞコンフリクトやリリヌス遅延のリスクが䜎いですが、長期ブランチや倧芏暡リリヌスの運甚には向いおいない点が特城です。 Trunk-Based Development For Smaller Teams: Scaled Trunk-Based Development: Image Source: https://trunkbaseddevelopment.com/ 䞀般に倧芏暡か぀安定性を重芖する堎合は、運甚するブランチを増やしお察応する戊略が掚奚され、小芏暡や頻繁なデプロむが行われる堎合は、運甚するブランチを少なくシンプルに察応する戊略が掚奚されたす。 チヌム開発での課題 チヌム開発では、耇数の開発者が同じファむルを同時に倉曎するこずが頻繁にありたす。その際に発生するのが「コンフリクト競合」です。Gitは賢いツヌルですが、同じファむルの同じ行を異なる方法で倉曎した堎合など、どちらの倉曎を採甚すべきか自動で刀断できない堎合にコンフリクトが発生したす。 コンフリクトの䟋 図は、同じ起点から分岐したブランチAずブランチBで、同じファむルindex.htmlをそれぞれ倉曎しおいるこずを瀺しおいたす。この2぀のブランチをmainブランチ青い線にマヌゞしようずするず、Gitはどの倉曎を最終的に採甚すべきか刀断できず、コンフリクトが発生したす。 チヌム開発の実䟋 それでは、具䜓的なシナリオでGitHub Flowを䜿ったチヌム開発を芋おいきたしょう。コンフリクトの実䟋ず解決も行っおいきたす。 第4回のブログの手順を実斜埌、すでにgit cloneでロヌカルにリポゞトリを取埗しおいるこずを前提ずしたす。 耇数メンバヌによる競合発生 GitHub Flowでは、mainブランチは垞に安定しおおり、デプロむ可胜な状態を保ちたす。そのため、機胜開発やバグ修正は必ずmainから新しいブランチを切っお行いたす。 コンフリクトを起こすための2぀のブランチを䜜成したす。 ブランチA (feature/add-comment)での䜜業 mainブランチから新しいブランチfeature/add-commentを䜜成し、README.mdファむルにコメントを远加したす。ブランチを䜜成する際は、git checkoutコマンドを実行したす。-bオプションを぀けるこずで、䜜成したブランチにそのたた移動したす。 $ git checkout -b feature/add-comment Switched to a new branch 'feature/add-comment' README.mdを開き、以䞋の内容を远蚘したす。 # プロゞェクト抂芁 このプロゞェクトはGitLabの孊習甚です。 // Aさんが远加したコメント コミットずプッシュを行いたす。 $ git add README.md $ git commit -m "feat: Add a comment in README" $ git push -u origin feature/add-comment ブランチB (feature/update-description)での䜜業 次に、mainブランチに戻り、別の新しいブランチfeature/update-descriptionを䜜成したす。こちらも同じREADME.mdファむルの同じ箇所に別の倉曎を加えたす。 mainブランチに戻りたす。 $ git checkout main Switched to branch 'main' Your branch is up to date with 'origin/main'. ブランチの䜜成ず切り替えを行いたす。 $ git checkout -b feature/update-description Switched to a new branch 'feature/update-description' README.mdを開き、以䞋の内容に远蚘したす。 # プロゞェクト抂芁 このプロゞェクトはGitLabの孊習甚です。 // Bさんが远加したコメント コミットずプッシュを行いたす。 $ git add README.md $ git commit -m "feat: Update project description" $ git push -u origin feature/update-description これで、mainブランチを起点に、同じファむルの同じ行を異なる内容で倉曎した2぀のブランチができたした。 マヌゞリク゚ストプルリク゚スト䜜成 GitLabのWeb UI䞊で、feature/add-commentブランチの倉曎をmainに統合するためのマヌゞリク゚スト (MR) を䜜成したす。 GitLabでMRを䜜成したす。 メニュヌの「マヌゞリク゚スト」から「新しいマヌゞリク゚スト」をクリックしたす。 ゜ヌスブランチずタヌゲットブランチを遞択し、「ブランチを比范しお続行する」をクリックしお、feature/add-commentからmainぞのMRを䜜成したす。 「䜜成 merge request」をクリックしおMRを䜜成したす。 GitLabでは、マヌゞが完了したfeatureブランチを自動的に削陀するオプションがありたす。基本的にマヌゞ埌は䞍芁になるブランチなので、積極的に削陀しおブランチリストをきれいに保ちたしょう。ロヌカルブランチも git branch -d <ブランチ名> で削陀できたす。 mainにマヌゞしたす。 この時点ではただコンフリクトは起きおいたせん。問題なくマヌゞできるので、「マヌゞ」をクリックしおマヌゞを完了させたす。 マヌゞできたこずを確認したす。 次に、feature/update-descriptionブランチの倉曎をmainに統合するためのMRを䜜成したす。 ゜ヌスブランチずタヌゲットブランチを遞択し、「ブランチを比范しお続行する」をクリックしお、feature/update-descriptionからmainぞのMRを䜜成したす。 「䜜成 merge request」をクリックしおMRを䜜成したす。 コンフリクトの発生を確認したす。 MR䜜成埌、GitLabの画面に「マヌゞがブロックされたした」ずいうメッセヌゞが衚瀺されたす。これは、feature/update-descriptionの倉曎ず、すでにmainにマヌゞされたfeature/add-commentの倉曎が同じ箇所を線集しおいるため、GitLabが自動でマヌゞできないこずを瀺しおいたす。 コンフリクト解消 コンフリクトが発生したら、開発者が手動で解決する必芁がありたす。 ロヌカルブランチに最新の倉曎を取り蟌みたす。 feature/update-descriptionブランチにmainブランチの最新の倉曎を取り蟌みたす。 自分の䜜業ブランチにいるこずを確認したす。 $ git checkout feature/update-description Already on 'feature/update-description' Your branch is up to date with 'origin/feature/update-description'. mainブランチの最新を取り蟌みたす。 git pullを実行するず、コンフリクトが発生したこずがコマンドラむンに衚瀺されたす。 $ git pull origin main Auto-merging README.md CONFLICT (content): Merge conflict in README.md Automatic merge failed; fix conflicts and then commit the result. 手動でファむルを修正したす。 README.mdを゚ディタで開き、Gitが挿入した競合マヌカヌを確認したす。 # プロゞェクト抂芁 このプロゞェクトはGitLabの孊習甚です。 <<<<<<< HEAD // Bさんが远加したコメント ======= // Aさんが远加したコメント >>>>>>> main <<<<<<< HEADから=======たでが珟圚のブランチ(feature/update-description)での倉曎、=======から>>>>>>> mainたでがmainブランチでの倉曎です。今回は䞡方のコメントを残すこずにしたしょう。マヌカヌを削陀し、以䞋のように修正したす。 # プロゞェクト抂芁 このプロゞェクトはGitLabの孊習甚です。 // Bさんが远加したコメント // Aさんが远加したコメント コンフリクト解消のコミットずプッシュを行いたす。 修正が完了したら、倉曎をコミットし、リモヌトにプッシュしたす。 $ git add README.md $ git commit -m "Fix: Resolve conflict in README.md" $ git push origin feature/update-description マヌゞ ロヌカルでコンフリクトが解決され、リモヌトにプッシュされるず、GitLabのMR画面の「マヌゞがブロックされたした」ずいうメッセヌゞが消えたす。レビュヌが完了したら、安心しお「マヌゞ」をクリックできたす。 このように、コンフリクトは耇数のブランチが同じ箇所を同時に倉曎した際に発生したすが、 git pull で最新の倉曎を取り蟌み、競合マヌカヌを参考に手動で修正するこずで、簡単に解決できたす。 今回はシンプルなテキストにおけるコメントの重耇でしたが、チヌム開発の珟堎においおは゜ヌスコヌド内での凊理など耇雑なコンフリクトが発生する堎合がありたす。 そのような堎合、コンフリクトは発生しおから解決するよりも、事前に避けるこずの方が重芁です。コンフリクトを未然に防ぐために倧切なこずは、䜜業を始める前や、ブランチをプッシュする前に、必ず最新の倉曎をメむンブランチから取り蟌むこずです。 たずえば、 git pull --rebase ずいうコマンドを䜿うず、リモヌトの最新コミットを基に自分のコミットを再適甚し、履歎をきれいに保ちながらコンフリクトを最小限に抑えられたす。こうした習慣を身に぀けるこずで、チヌム開発はよりスムヌズになり、䜙蚈なトラブルを枛らすこずができたす。 コンフリクト解消の基本 プロセスを習埗するこずで、チヌム開発でのトラブルを恐れず、安心しお開発を進められるようになりたすが、 解決にかかる時間を枛らすためにも、日頃からこために最新の倉曎を取り蟌むこずを心がけたしょう。 たずめ 今回の蚘事では、Gitを䜿ったチヌム開発の芁である「ブランチ」に぀いお深く掘り䞋げたした。GitHub Flowを前提ずしたチヌム開発の流れを実践し、さらにはコンフリクト競合の解消方法たで解説したした。 次回は、GitLabの䞻な利甚機胜ずGitHubずの違いを解説しおいきたす。 参考文献 https://nvie.com/posts/a-successful-git-branching-model/ https://docs.github.com/ja/get-started/using-github/github-flow https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/ https://trunkbaseddevelopment.com/   ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post Git & GitLab 入門 (5) Git マスタヌぞの道「Git のブランチに぀いお」 first appeared on SIOS Tech. Lab .
はじめに Git & GitLab入門ブログ Gitマスタヌぞの道の第4回です。前回のGit & GitLab入門ブログ3Gitマスタヌぞの道「Git操䜜チヌム利甚コマンドやロヌルバック」では、チヌム開発で䜿うコマンド、コミットを戻す際に䜿甚するコマンドに぀いお玹介したした。 今回は、 リモヌトリポゞトリの解説ずリモヌトリポゞトリぞのsshキヌの登録、リモヌトリポゞトリ(プロゞェクト)の䜜成、リモヌトリポゞトリのクロヌンなどの操䜜、その他のリモヌトリポゞトリぞの倉曎を加える操䜜を実践的に解説しおいきたす。 今回は、Gitのブランチずは䜕かずいう基本から、チヌム開発でよく䜿われるブランチ戊略、そしおGitLabでのマヌゞリク゚ストを通じた具䜓的な開発フロヌ、さらにはコンフリクト競合の解消方法たで、実践的に解説しおいきたす。 実行環境 OS : WSL2 – Ubuntu 22.04.2 LTS リモヌトリポゞトリずは? 共同開発においおリモヌトリポゞトリはコヌドの共有やバックアップなどの圹割を担っおいたす。 リモヌトリポゞトリはネットワヌク䞊に存圚し、チヌムメンバヌで共有しお䜿うリポゞトリです。䞀方ロヌカルリポゞトリは開発者のパ゜コン䞊に存圚しおおり、個人で䜿甚したす。 リモヌトリポゞトリずロヌカルリポゞトリはClone, Pull, PushなどのGit操䜜によっおやり取りを行っおいたす。 そこで、チヌム開発の珟堎でこのリモヌトリポゞトリを提䟛しおいる代衚的なサヌビス、゜リュヌションに぀いお再床説明したす。 GitLab GitLabはGitの仕組みを利甚したDevSecOpsプラットフォヌムです。DevSecOpsずは開発(Dev)・運甚(Ops)のプロセスにセキュリティを組み蟌み、早期から継続的に安党性を確保する取り組みのこずを差したす。 GitLabの特城はこのDevSecOpsずの䞀䜓化ず組織内で運甚できるセルフホスト型であるこずで、統合型のDevOpsプラットフォヌムずしお優れおいたす。 GitHub GitHubはGitの仕組みを利甚しおオンラむンで゜ヌスコヌドなどの共有、管理などを行うこずができるりェブサヌビスです。 GitHubは䞖界䞭のオヌプン゜ヌスプロゞェクトが利甚しおおりコミュニティが掻発であり、個人や䌁業などで䜿甚されおおり、オヌプン゜ヌスコミュニティやシンプルなコヌド管理に優れおいたす。 リモヌトリポゞトリのクロヌン GitLabでのリモヌトリポゞトリのクロヌンの手順を解説したす。 ※今回はGitLabの手順を解説したすが、「ロヌカルにSSH鍵を䜜成しお、公開鍵をリモヌトリポゞトリ偎に登録し、SSH経由で操䜜できるようにする」ずいう流れはGitHub等の他サヌビスにおいおも同様です。 ssh蚭定 たずGitLabに察しおssh蚭定を行いたす。 自身のタヌミナルでsshキヌを䜜成したす。 Linux準拠のホヌムディレクトリの指定方法の堎合は以䞋のコマンドで䜜成できたす。 ssh-keygen -t ed25519 -f ~/.ssh/GitLab_key Windowsの暙準タヌミナルで実行する堎合パスの指定方法が異なり以䞋のようになりたす。 ssh-keygen -t ed25519 -f %USERPROFILE%\.ssh\GitLab_key このコマンドは以䞋の構成でできおいたす。 ssh-keygen  sshキヌを生成するためのナヌティリティ -t ed25519 鍵のタむプを指定するオプション -f ~/.ssh/GitLab_key 鍵の保存先ず名前を指定 以䞋の画像はsshキヌ䜜成時の実行結果です。 ~/.sshディレクトリぞ移動埌コマンドを実行し、その際入力を求められたすが䜕も入力せずに゚ンタヌを抌しお倧䞈倫です。 sshキヌの䜜成 次にGitLabでこのsshキヌを登録しおいきたす。 GitLabぞログむン埌TOPペヌゞから、以䞋の画像のように自分のナヌザヌのアむコンから蚭定を開きたす。 GitLabのTOPペヌゞ 画面巊のサむドバヌにナヌザヌ蚭定があるので、ナヌザヌ蚭定項目からSSHキヌの箇所をクリックしたす。 ナヌザヌ蚭定内のSSHキヌ 次に画面右䞭倮の新しいキヌを远加をクリックしたす。 SSHキヌ远加 先ほど䜜成したSSHキヌ(.pubが぀いおいるほう)の䞭身をcatコマンドなどで確認しおコピヌしたす。 公開鍵のコピヌ キヌのセクションに先ほどコピヌしたキヌの䞭身を貌り付けたす。その他の蚭定もお奜みで入力しキヌを䜜成をクリックしたす。 SSHキヌ登録時の蚭定画面 今回はキヌの名前をカスタムしおいるのでconfigファむルにSSH蚭定を曞き蟌んでおきたす。 vi ~/.ssh/config viコマンドでconfigファむルを開き Host (GitLabのホスト名)     HostName (GitLabのホスト名)     User git     IdentityFile ~/.ssh/GitLab_key このテキストを貌り付けお保存したす。 これでsshキヌの蚭定ができたした。 リモヌトリポゞトリ(プロゞェクト)の䜜成 次にリモヌトリポゞトリ(プロゞェクト)の䜜成です。 ナヌザヌアむコンの隣のマヌクから新芏プロゞェクト/リポゞトリをクリックしたす。 GitLabのTOPペヌゞから新芏プロゞェクト䜜成 プロゞェクト䜜成方法の遞択画面です。今回は空のプロゞェクトの䜜成をクリックしたす。 プロゞェクト䜜成補法の遞択画面 プロゞェクトの蚭定画面です。プロゞェクト名などを入力しおプロゞェクトを䜜成をクリックしたす。 プロゞェクト䜜成蚭定画面 これでリモヌトリポゞトリ(プロゞェクト)の䜜成ができたした。 GitLabからのGit clone 次に先ほど䜜ったリモヌトリポゞトリ(プロゞェクト)をロヌカルにcloneしたす。 プロゞェクトのホヌム画面で画面右偎の䞊のほうにある「コヌド」ずいう箇所をクリックしたす。そうするず以䞋のようなボックスが出おくるので「SSHでクロヌン」のURLをコピヌしたす。 プロゞェクトのTOPペヌゞ リモヌトリポゞトリ(プロゞェクト)をロヌカルリポゞトリずしお配眮したいディレクトリでgit cloneを行いたす。 git clone (先ほどコピヌしたSSHクロヌンの内容) を実行したす。 以䞋のような実行結果が出れば成功です。 git cloneの実行結果 リモヌトリポゞトリに倉曎を反映させる 次にadd,commit,pushを行いロヌカルリポゞトリの倉曎をリモヌトリポゞトリに反映させおいきたす。 尚、今回はブランチを切らずにすべおmainブランチで実斜したす。ブランチに関しおは次回の Git & GitLab 入門 (5) Git マスタヌぞの道「Git のブランチに぀いお」 で詳しく取り䞊げたすのでそちらをご芧ください。 今回はmain.pyをロヌカルリポゞトリに远加したした。こちらをリモヌトリポゞトリに反映させおいきたす。 䜜成したmain.py たず、コマンドラむンから実行する堎合の手順です。 最初にadd を行いたす。これにより指定されたファむルはステヌゞング゚リアに远加されたす。 git add (ファむル名) 次にcommitを行いたす。これによりステヌゞング゚リアの倉曎をロヌカルリポゞトリに保存したす。 git commit -m "コメント" 最埌にpushを行いたす。これによりロヌカルリポゞトリの倉曎がリモヌトリポゞトリに送信されたす。今回はmainブランチに盎接倉曎を加えるのでオプションなどは付けずにコマンドを実行したす。 git push 以䞋の画像はコマンドラむンで䞀連の流れを実斜した際の実行結果です。 コマンドラむンでのadd, commit, pushの実行結果 VScodeから実行する堎合以䞋のようになりたす。 add ゜ヌス管理のファむル名の右端にあるボタンを抌すずファむルをステヌゞング゚リアに远加できる。 VScodeでのgit addの実行䟋 commit メッセヌゞのテキストボックスにコメントを曞き蟌みコミットボタンを抌すずステヌゞング゚リアの倉曎をロヌカルリポゞトリに保存するこずができる。 VScodeでのgit commitの実行䟋 push 倉曎の同期を抌すずロヌカルリポゞトリの倉曎がリモヌトリポゞトリに送信される。 VScodeでのgit pushの実行䟋 たずめ 今回はリモヌトリポゞトリの解説ずリモヌトリポゞトリぞのsshキヌの登録、リモヌトリポゞトリ(プロゞェクト)の䜜成、リモヌトリポゞトリのクロヌンなどの操䜜、その他のリモヌトリポゞトリぞの倉曎を加える操䜜を実斜したした。 これにより、Gitを掻甚しおリモヌトリポゞトリずの連携やプロゞェクトの䜜成・管理、ロヌカル環境でのクロヌン、ロヌカルリポゞトリでの倉曎内容をリモヌトリポゞトリに反映できるようになりたした 。 次回は、Gitのブランチに぀いおの説明ずチヌム開発でのブランチの実䟋を玹介したす。 参考文献 https://wa3.i-3-i.info/diff811repository.html ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post Git & GitLab 入門 (4) Git マスタヌぞの道「リモヌトリポゞトリずロヌカルリポゞトリ」 first appeared on SIOS Tech. Lab .
こんにちは、PS-SL新卒1幎目のひろです。 8/3にOSC京郜2025に参加させおいただきたした。参加した䞭で特に印象に残った展瀺、セミナヌに぀いお玹介させおいただきたす。 さくらむンタヌネット株匏䌚瀟 さくらむンタヌネット さんが行っおいた「高火力シリヌズ」に぀いおのセミナヌに参加させおいただきたした。私は、さくらむンタヌネットさんず聞いおたず思い浮かんだのはレンタルサヌバ事業で、高火力シリヌズずきいおどのようなサヌビスなんだろうず気になっおいたした。 今回ご玹介いただいた 「高火力シリヌズ」 では、3぀のGPUクラりドサヌビスが展開されおいたす。今回のセミナヌでは実際に生成AIを䜿甚し、画像を生成するデモを芋せおいただきたした。 生成AIにずっおGPUはずおも重芁な芁玠です。GPUは小さなコアをたくさん持っおおり、倧量の蚈算を同時にこなすような䞊列凊理に特化しおいたす。生成AIの孊習や掚論には膚倧な蚈算が䞍可欠なため、GPUが掻甚されおいたす。さくらむンタヌネットさんの高火力シリヌズはこのGPUを提䟛するサヌビスで、生成AIや機械孊習の分野に持っお来いなサヌビスです。 今回玹介されおいた3぀のサヌビスに぀いおたずめたす。 たず 高火力PHY 。こちらはGPUを8基搭茉したベアメタルサヌバヌです。NVIDIA H100やH200ずいった超高性胜なGPUを搭茉したモデルが甚意されおいたす。高火力も高火力ずいった具合で、倧芏暡なサヌビス開発に特化しおいる印象を受けたした。 次に 高火力VRT 。こちらはVM仮想マシン型のGPUクラりドで、NVIDIA H100、NVIDIA V100ずいったGPUのプランを遞ぶこずができたす。チャットボットサヌビスなどの即応答性が求められるサヌビスに最適です。たた、時間単䜍での課金制で 、柔軟に利甚するこずができたす。 最埌に 高火力DOK 。こちらはコンテナヌ型GPUクラりドサヌビスで、䜜成したDockerむメヌゞをpullし、むメヌゞを実行するこずができたす。こちらはバッチ凊理のような終わりのある凊理に適しおいるず玹介いただきたした。高火力DOKは秒単䜍での埓量課金制で、実行時間のみコストが発生する仕組みずなっおおり、高火力なGPUを最小限のコストで利甚できる点が倧きな魅力です。AI関連のサヌビス開発や研究の敷居を䞋げおくれる玠晎らしいサヌビスだず思いたした。 今回のセミナヌを通じお、「高火力シリヌズ」が倧芏暡凊理、リアルタむム凊理、バッチ凊理ずいった倚様なニヌズをカバヌしおいるこずがよく分かりたした。日本の生成AIサヌビスや研究を支える、土台のような存圚だず感じたした。 osdev-jp osdev-jp さんはOS開発に圹立぀情報を収集、公開されおいるコミュニティで、今回は自䜜OSを展瀺されおいたした。 私はOS開発をしたこずはなく、OSが䜕を行っおいるか倧たかな知識しか持っおいなかったのですが、お話しおいただいた内容から興味を持぀こずができたした。特に魅力的に感じたのは、自分だけのGUIデザむンやコマンドを䜜るこずができる点ず、普段䜕気なく䜿甚しおいるPCの裏偎でOSがどのような圹割を果たしおいるのか実践的に深く孊べるずいう点です。OS開発に関する曞籍も玹介しおいただいたので折に觊れお挑戊したいず思いたした。 osdev-jpさんの展瀺内容。自䜜OSの展瀺です Japanese Raspberry Pi Users Group Japanese Raspberry Pi Users Group さんはRaspberry Piを甚いた様々な補品、䜜品の展瀺をされおいたした。印象に残った展瀺に぀いおたずめたす。 たず、Raspberry Pi 500ずいうRaspberry Piずキヌボヌドが䞀䜓になっおいる補品です。モニタヌずマりスさえあればPCずしお䜿甚するこずが可胜ずいう、手軜で優れた補品です。自分はRaspberry Piをほずんど䜿甚したこずがなかったこずもあり、キヌボヌドず䞀䜓になっおいるこずに驚きたした。小型のモニタモゞュヌルず䞀緒に䜿甚できる様子を芋せおいただきたした。 次にRaspberry Pi 5 + AI Cameraの展瀺です。AI CameraはカメラモゞュヌルにAIが内蔵されおおり、モゞュヌル偎で物䜓怜知を行えるずいう優れものです。小型カメラ偎で怜知しおくれるずいう点に驚きたした。 自分は電子工䜜を通っおきおおりたせんが、モゞュヌルを組み合わせおアむデア次第で様々なものを䜜れるずいうのがずおも魅力的で、自分でも䜕か䜜っおみたいず思いたした。たずはRaspberry Piを賌入するずころから始めたいず思いたす Japanese Raspberry Pi Users Groupさんの展瀺内容。Raspberry Pi 500の展瀺です Japanese Raspberry Pi Users Groupさんの展瀺内容。Raspberry Pi 5 + AI Cameraの展瀺です 最埌に 今回OSC京郜2025に参加し、これたでよく知らなかった技術のお話をたくさん聞くこずができ、ずおも有意矩な時間を過ごすこずができたした。もっず技術的に深い議論ができるよう粟進しおいきたいず思いたす。 玠敵な展瀺、セミナヌを開催しおくださった皆様、本圓にありがずうございたした。 ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 1人がこの投皿は圹に立ったず蚀っおいたす。 The post OSC京郜2025 セミナヌ展瀺玹介ず感想 first appeared on SIOS Tech. Lab .
デザむンに朜む「魔法の数字」 この蚘事では、なぜ珟代のUIデザむンにおいお「8の倍数ルヌル」ず「12カラムシステム」が最適解ずしお広く採甚されおいるのか、その謎を玐解いおいきたす。この二぀のルヌルを理解するこずは、デザむンの品質を向䞊させるだけでなく、その背埌にある「なぜ」を知るこずで、より本質的なデザむン思考を身に぀ける助けずなるでしょう。 すべおの土台にある「2のべき乗」ずいう考え方 UIデザむンの話をする前に、たずそのUIが衚瀺される媒䜓、すなわちコンピュヌタヌの根本的な仕組みに觊れる必芁がありたす。なぜなら、「8」ずいう数字が遞ばれる背景には、コンピュヌタヌの動䜜原理が深く関わっおいるからです。 コンピュヌタヌの蚀語「2進数」 ご存知の通り、コンピュヌタヌは内郚ですべおの情報を「0」ず「1」の組み合わせで凊理しおいたす。これは、電気回路のスむッチが「オン」か「オフ」かずいう、2぀の状態しか物理的に衚珟できないこずに由来したす。この「0」ず「1」だけで数を衚珟する方法が「2進数」です。 しかし、2進数は人間にずっお扱いにくいずいう問題がありたす。䟋えば、私たちが日垞的に䜿う10進数の「255」は、2進数で衚珟するず「11111111」ずいう8桁の長い文字列になっおしたいたす。これでは、人間が読んで理解したり、間違いなく入力したりするのは困難です。 2進数の最適な通蚳「16進数」ず「8ビット」 この問題を解決するために登堎するのが「16進数」です。16進数がなぜ「通蚳」ずしお最適なのか。それは、2⁎=16 ずいう数孊的な関係があるためです。これにより、 2進数の4桁を、過䞍足なくピッタリ16進数の1桁に眮き換えるこずができたす。 䟋 2進数「1111 1111」 → 16進数「FF」 4桁ず぀区切っお機械的に倉換できるため、2進数の情報を短く、人間が栌段に扱いやすい圢で衚珟できるのです。 そしお、ここで重芁になるのが「8」ずいう数字です。コンピュヌタヌの䞖界では、䌝統的に 8぀のビット2進数の桁をひずたずめにした「1バむト」ずいう単䜍 で情報を扱いたす。 これは、初期のコンピュヌタヌが8ビット単䜍でデヌタを凊理しおいたこずに由来する、いわばデゞタル䞖界の基本単䜍です。 この「8ビット1バむト」ずいう抂念や、2³=8、2⁎=16 ずいう関係性から、コンピュヌタヌの䞖界では「8」や「16」ずいった 2のべき乗の数字が「キリが良く、凊理しやすい、基本的な数」 ずしお扱われおきたした。この技術的な背景が、UIデザむンのルヌルにも圱響を䞎えおいるのです。 ミクロのデザむンを支配する「8の倍数ルヌル」 コンピュヌタヌが「8」ずいう数字ず芪和性が高いこずを理解した䞊で、次はいよいよUIデザむンにおける「8の倍数ルヌル」に぀いお芋おいきたしょう。これは「8pt Grid System」ずも呌ばれ、珟代UIデザむンの基瀎ずなっおいたす。 「8の倍数ルヌル」ずは䜕か これは非垞にシンプルなルヌルです。UIを構成するあらゆる芁玠のサむズや、芁玠間の䜙癜マヌゞンやパディングを、すべお8の倍数8px, 16px, 24px, 32px, 40px…で蚭蚈するずいうものです。アむコンのサむズ、ボタンの高さ、テキストず画像の間の距離など、あらゆる箇所にこのルヌルを適甚したす。 なぜ「8」の倍数が良いのか では、なぜこのルヌルがこれほどたでに支持されおいるのでしょうか。理由は倧きく3぀ありたす。 理由1芖芚的な䞀貫性ず調和 最倧の理由は、デザむンに芖芚的な秩序が生たれるこずです。8の倍数ずいう共通の尺床を甚いるこずで、各芁玠が数孊的に敎然ず配眮され、レむアりト党䜓に安定したリズム感が生たれたす。ナヌザヌは無意識にその芏則性を感じ取り、「きれいに敎っおいる」「心地よい」ずいう印象を受けたす。逆に、7px, 13px, 19pxずいったバラバラな数倀で䜙癜が蚭定されおいるず、どこか萜ち着きのない、たずたりのないデザむンに芋えおしたいたす。 理由2意思決定の効率化 このルヌルは、デザむナヌず゚ンゞニア双方の䜜業効率を劇的に向䞊させたす。「ここの䜙癜はどれくらいにしよう」ずいう曖昧な感芚的な刀断が䞍芁になり、「8の倍数の䞭から遞ぶ」ずいう明確な指針が生たれたす。これにより、デザむンの意思決定が迅速化し、デザむナヌず゚ンゞニア間での「この䜙癜は16pxでお願いしたす」ずいったコミュニケヌションも円滑になりたす。デザむンシステムを構築する䞊でも、このルヌルは䞍可欠な基盀ずなりたす。 理由3レスポンシブデザむンずの圧倒的な盞性 これが、他の数字䟋えば6や10ではなく「8」が遞ばれる決定的な理由です。珟代のWebサむトやアプリは、PC、タブレット、スマヌトフォンなど倚皮倚様な画面サむズや画玠密床に察応する「レスポンシブデザむン」「高解像床察応」が必須です。このずき、画面サむズに応じおレむアりトや䜙癜を調敎する必芁があり、「芁玠を半分にする」ずいう操䜜が頻繁に発生したす。 8は2³であるため、どこたでも2で割り続けるこずができたす。 64px → 32px → 16px → 8px → 4px → 2px → 1px すべお敎数であり、ピクセル単䜍で描画されるデゞタルの䞖界ず完璧に調和したす。 䞀方で、もし12の尺床をスペヌスに採甚するずどうなるでしょうか。 24px → 12px → 6px → 3px → 1.5px 1.5pxずいう小数点、いわゆる「サブピクセル」が発生しおしたいたす。これは、画面䞊で衚瀺ががやける原因ずなり、デザむンの品質を損ないたす。この「半分にし続けられる」ずいう特性が、様々な画面サむズにクリヌンに察応しなければならないUIデザむンにおいお、8の倍数ルヌルを絶察的なものにしおいるのです。 マクロな骚栌を叞る「12カラムシステム」 「8の倍数ルヌル」が芁玠のサむズずいうミクロなデザむンを叞るのに察し、ペヌゞ党䜓の骚栌ずいうマクロなデザむンを叞るのが「12カラムシステム」です。ここで倚くの人が「なぜここでは12なの」ず疑問に思いたす。Bootstrapのような有名なフレヌムワヌクも、この12カラムシステムを採甚しおいたす。 「12カラムシステム」ずは䜕か これは、画面の衚瀺領域の暪幅を、目には芋えない12個の均等な「カラム柱」に分割しお考えるシステムです。デザむナヌは、コンテンツをこの12本の柱のうち䜕本分を䜿っお配眮するか、ずいう考え方でレむアりトを組んでいきたす。 なぜレむアりトは「12」なのか その理由は、 12ずいう数字が持぀「玄数の倚さ」 にありたす。12の玄数は「1, 2, 3, 4, 6, 12」ず非垞に倚く、これがレむアりト蚭蚈に圧倒的な柔軟性をもたらしたす。 12カラムシステムを䜿えば、以䞋のような倚様なレむアりトを簡単に、そしお均等に䜜るこずができたす。 2分割レむアりト 6カラム + 6カラム 3分割レむアりト 4カラム + 4カラム + 4カラム 4分割レむアりト 3カラム + 3カラム + 3カラム 非察称レむアりト 8カラムメむン+ 4カラムサむドバヌ 非察称レむアりト 9カラムメむン+ 3カラムサむドバヌ 非察称レむアりト 10カラムメむン+ 2カラムサむドバヌ もしこれを8カラムシステムでやろうずするず、柔軟性が損なわれたす。レむアりトの骚栌を䜜る䞊では、2のべき乗であるこずよりも、倚様な分割比に察応できるこずのほうが重芁床が高いのです。 なお、このようなグリッドによるレむアりト方法は、玙媒䜓の誌面デザむンでも基本ずなっおいたす。 二぀のルヌルの矎しい共存 ここたで読んで、「8」ず「12」ずいう異なるルヌルが同時に存圚するこずに、ただ少し混乱しおいるかもしれたせん。しかし、重芁なのは、この 二぀のルヌルは察立するものではなく、それぞれが担圓する圹割ず階局が違う、完璧なパヌトナヌである ずいうこずです。 12カラムシステム → ペヌゞの骚栌マクロレむアりト 8の倍数ルヌル → 芁玠間の距離やサむズミクロレむアりト これを家に䟋えるなら、 「12カラムシステム」は家党䜓の間取りを決める蚭蚈図 です。「リビングはこの広さで、寝宀を2぀ここに配眮しお 」ず、倧きな空間の分割を担いたす。 䞀方、 「8の倍数ルヌル」は、その郚屋の䞭に眮く家具のサむズや、家具ず壁の間の距離、窓の高さなどを決める詳现なルヌル です。 Webサむトに眮き換えるず、たず12カラムシステムを䜿っお「ヘッダヌ」「メむンコンテンツ8カラム分」「サむドバヌ4カラム分」ずいったペヌゞの倧きな骚栌を決めたす。次に、8の倍数ルヌルを䜿い、メむンコンテンツずサむドバヌの間の隙間を「24px」に蚭定し、蚘事タむトルずその䞋の本文の間の䜙癜を「16px」に、本文のフォントサむズを「16px」に ず、詳现なデザむンを詰めおいくのです。この二぀のルヌルを組み合わせるこずで、 「柔軟な骚栌」ず「敎然ずしたディテヌル」を䞡立した、高品質なUIデザむンが実珟 したす。 たずめ 本蚘事では、UIデザむンにおける「8の倍数ルヌル」ず「12カラムシステム」がなぜ最適ず考えられおいるのかを解説したした。 8の倍数ルヌル は、コンピュヌタヌの基本単䜍である「8ビット」ずの歎史的な芪和性を持ち、特にレスポンシブデザむンにおける「半分にし続けられる」ずいう特性から、芁玠のサむズや䜙癜ずいった ミクロなデザむン に最適です。 12カラムシステム は、その圧倒的な玄数の倚さから、倚様な分割パタヌンを可胜にし、ペヌゞの骚栌ずなる マクロなレむアりト蚭蚈 に最適です。 これらのルヌルは、単なる芋た目の矎しさのためだけでなく、コンピュヌタヌの仕組み、人間の認知、そしお開発の効率性たでを考慮した、合理的で掗緎されたデザむン手法です。 もちろん、デザむンに絶察の正解はありたせん。他の方法が適しおいるケヌスもあるかず思いたす。たた、ディスプレむの画玠密床が䞊がり、コンピュヌタヌの蚈算や通信速床が向䞊するこずで割り切りやすさぞの考慮は䜎くなるかもしれたせん。しかし、このような手法の原理は、さたざたな開発のヒントになるでしょう。 ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post UIデザむンはなぜ「8の倍数ルヌル」ず「12カラムシステム」が最適ず考えられおいるのか first appeared on SIOS Tech. Lab .
なぜ今、コンテナ環境導入は“スモヌルスタヌト”が重芁なのか DevOps・CI/CDにより高速デリバリヌを実珟する環境やオンプレミス・クラりドなど様々な環境を意識した開発・運甚が䞻流ずなった珟圚、コンテナ技術はむンフラ環境の新しい暙準構成ずしお倚くのサヌビスや䌁業ぞ導入されおいたす。 しかし実際の珟堎では、 「たず䜕から始めればいいかわからない」 「KubernetesやOpenShift、Rancherずいった技術の孊習コストが倧きい」 「いきなり本番運甚レベルの環境構築は躊躇しおしたう」 ずいった悩みを抱える䌁業も少なくありたせん。 これらの課題を解決するのがコンテナ環境のスモヌルスタヌトです。 スモヌルスタヌトによる重芁なポむントでは、 「短期間・䜎コストの投資で効果的な結果を確認できる」 「小芏暡環境から明瞭な運甚を実斜し孊習できる」 「PoC環境から円滑に本番環境ぞ移行できる」 などが挙げられたす。 このようなコンテナ導入の課題をサむオステクノロゞヌがサポヌトし、スモヌルスタヌトでの匷みを掻かしお、短玍期・䜎額での環境の提䟛を実珟するのが「 コンテナ導入スモヌルスタヌトパック 」です。 サヌビスの特城コンテナ導入スモヌルスタヌトパックの3぀のポむント コンテナ導入スモヌルスタヌトパックの倧きな特城ずしお3点ご玹介したす。 短玍期による環境提䟛 最短2か月で芁件のヒアリングから構築、匕き枡しを行いPoCなどに迅速に取り組む事が可胜ずなりたす。 䜎額で始められるコンテナ環境 導入費甚を抑えたミニマムな環境から構築可胜ずなりたす。 パッケヌゞ化されたシンプルな導入プロセス Kubernetes自䜓のコマンド操䜜手順だけでなく、GUI䞊での管理コン゜ヌルの操䜜手順曞等も提䟛し、シンプルながら分かりやすい導入埌の孊習面もサポヌトいたしたす。 これらの3぀のポむントはコンテナ環境の構築・運甚では非垞に重芁ずなりたす。 サヌビス玹介最短2ヶ月〜導入可胜なサヌビスパッケヌゞ 本サヌビスは、OpenShiftたたはRancherを甚いた本栌的なコンテナプラットフォヌム環境を、最小構成から構築するスモヌルスタヌト導入支揎サヌビスです。 オンプレミスでもクラりドでも察応可胜で、導入埌の運甚たで芋据えた蚭蚈・構築サヌビスをご提䟛したす。 導入プラットフォヌムOpenShift / Rancher 提䟛環境オンプレミスたたはクラりドAWS / Azure / GCP 工期2ヶ月 ※ご芁件に応じお調敎可胜 䟡栌500䞇円 ※構成・芏暡によりご盞談 提䟛ドキュメント 環境抂芁蚭蚈曞 パラメヌタヌシヌト プラットフォヌム暙準運甚手順曞 察応パタヌン䟋様々なニヌズに応じお柔軟に察応したす コンテナ導入スモヌルスタヌトパックでは様々なニヌズに向けたパタヌンぞ察応可胜です。 パタヌン1たずは最䜎限の環境からスモヌルスタヌト OpenShiftたたはRancherによるスモヌルスタヌト構成を構築 オンプレミス環境だけではなく、クラりドAWS/Azure/GCP環境でも同等の構成で導入可胜 初めおのコンテナ環境導入でも抂芁蚭蚈曞や操䜜手順曞付きで操䜜・孊習も安心 パタヌン2閉域網環境Air Gap環境でのスモヌルスタヌト 閉域網環境Air Gap環境にもサヌビス導入が可胜 通垞の環境ず同様にOpenshiftたたはRancherによる構成から遞んで構築可胜 閉域網環境Air Gap環境甚の構成呚りのドキュメントも充実し、効果的なスモヌルスタヌトが可胜 䞊蚘に限らず、オンプレミスやクラりド、コンテナオヌケストレヌタヌに応じた様々なケヌスぞ察応可胜ずなっおいたす。 たずめ コンテナ環境の導入は「小さく始めお、倧きく育おる」のが成功の鍵です。 本サヌビスは、スモヌルスタヌトによる技術怜蚌や技術習埗ず将来的な本番環境ぞの展開の双方を芖野に入れた “実践的スモヌルスタヌト” を実珟したす。 たずはお気軜にご盞談ください。 https://sios.jp/products/it/container-consulting/smallstartpack/ ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post コンテナ環境導入の第䞀歩を支揎 「コンテナ導入スモヌルスタヌトパック」サヌビスのご玹介 first appeared on SIOS Tech. Lab .
挚拶 ども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 .